Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing network access management. This feature specifies the following security functions:

· Authentication—Identifies users and verifies their validity.

· Authorization—Grants different users different rights, and controls the users' access to resources and services. For example, you can permit office users to read and print files and prevent guests from accessing files on the device.

· Accounting—Records network usage details of users, including the service type, start time, and traffic. This function enables time-based and traffic-based charging and user behavior auditing.

AAA uses a client/server model. The client runs on the access device, or the network access server (NAS), which authenticates user identities and controls user access. The server maintains user information centrally. See Figure 1.

Figure 1 AAA network diagram

To access networks or resources beyond the NAS, a user sends its identity information to the NAS. The NAS transparently passes the user information to AAA servers and waits for the authentication, authorization, and accounting result. Based on the result, the NAS determines whether to permit or deny the access request.

AAA has various implementations, including RADIUS, HWTACACS, and LDAP. RADIUS is most often used.

The network in Figure 1 has one RADIUS server and one 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 use the RADIUS server for accounting.

You can choose 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 deploy an authentication server. If network usage information is needed, you would also configure an accounting server.

The device performs dynamic password authentication.

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol that uses a client/server model. The protocol can protect networks against unauthorized access and is often used in network environments that require both high security and remote user access.

The RADIUS authorization process is combined with the RADIUS authentication process, and user authorization information is piggybacked in authentication responses. RADIUS uses UDP port 1812 for authentication and UDP port 1813 for accounting.

RADIUS was originally designed for dial-in user access, and has been extended to support additional access methods, such as Ethernet and ADSL.

Client/server model

The RADIUS client runs on the NASs located throughout the network. It passes user information to RADIUS servers and acts on the responses to, for example, reject or accept user access requests.

The RADIUS server runs on the computer or workstation at the network center and maintains information related to user authentication and network service access.

The RADIUS server operates using the following process:

1. Receives authentication, authorization, and accounting requests from RADIUS clients.

2. Performs user authentication, authorization, or accounting.

3. Returns user access control information (for example, rejecting or accepting the user access request) to the clients.

The RADIUS server can also act as the client of another RADIUS server to provide authentication proxy services.

The RADIUS server maintains the following databases:

· Users—Stores user information, such as the usernames, passwords, applied protocols, and IP addresses.

· Clients—Stores information about RADIUS clients, such as shared keys and IP addresses.

· Dictionary—Stores RADIUS protocol attributes and their values.

Figure 2 RADIUS server databases

Information exchange security mechanism

The RADIUS client and server exchange information between them with the help of shared keys, which are preconfigured on the client and server. A RADIUS packet has a 16-byte field called Authenticator. This field includes a signature generated by using the MD5 algorithm, the shared key, and some other information. The receiver of the packet verifies the signature and accepts the packet only when the signature is correct. This mechanism ensures the security of information exchanged between the RADIUS client and server.

The shared keys are also used to encrypt user passwords that are included in RADIUS packets.

User authentication methods

The RADIUS server supports multiple user authentication methods, such as PAP, CHAP, and EAP.

Basic RADIUS packet exchange process

Figure 3 illustrates the interactions between a user host, the RADIUS client, and the RADIUS server.

Figure 3 Basic RADIUS packet exchange process

RADIUS uses in the following workflow:

1. The host sends 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. The request includes the user's password, which has been processed by the MD5 algorithm and shared key.

3. The RADIUS server authenticates the username and password. If the authentication succeeds, the server sends back an Access-Accept packet that contains the user's authorization information. If the authentication fails, the server returns an Access-Reject packet.

4. The RADIUS client permits or denies the user according to the authentication result. If the result permits the user, the RADIUS client sends a start-accounting request (Accounting-Request) packet to the RADIUS server.

5. The RADIUS server returns an acknowledgment (Accounting-Response) packet and starts accounting.

6. The user accesses the network resources.

7. The host requests the RADIUS client to tear down the connection.

8. The RADIUS client sends a stop-accounting request (Accounting-Request) packet to the RADIUS server.

9. The RADIUS server returns an acknowledgment (Accounting-Response) and stops accounting for the user.

10. The RADIUS client notifies the user of the termination.

RADIUS packet format

RADIUS uses UDP to transmit packets. The protocol also uses a series of mechanisms to ensure smooth packet exchange between the RADIUS server and the client. These mechanisms include the timer mechanism, the retransmission mechanism, and the backup server mechanism.

Figure 4 RADIUS packet format

Descriptions of the fields are as follows:

· The Code field (1 byte long) indicates the type of the RADIUS packet. Table 1 gives the main values and their meanings.

Table 1 Main values of the Code field

Code	Packet type	Description
1	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.
2	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.
3	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.
4	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.
5	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.

· The Identifier field (1 byte long) is used to match response packets with request packets and to detect duplicate request packets. The request and response packets of the same exchange process for the same purpose (such as authentication or accounting) have the same identifier.

· The Length field (2 bytes long) indicates the length of the entire packet (in bytes), 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 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 authentication, authorization, and accounting information. This field can contain multiple attributes, each with the following subfields:

? Type—Type of the attribute.

? Length—Length of the attribute in bytes, including the Type, Length, and Value subfields.

? Value—Value of the attribute. Its format and content depend on the Type subfield.

Commonly used RADIUS attributes are defined in RFC 2865, RFC 2866, RFC 2867, and RFC 2868. For more information, see "Commonly used standard RADIUS attributes."

Table 2 Commonly used RADIUS attributes

No.	Attribute	No.	Attribute
1	User-Name	45	Acct-Authentic
2	User-Password	46	Acct-Session-Time
3	CHAP-Password	47	Acct-Input-Packets
4	NAS-IP-Address	48	Acct-Output-Packets
5	NAS-Port	49	Acct-Terminate-Cause
6	Service-Type	50	Acct-Multi-Session-Id
7	Framed-Protocol	51	Acct-Link-Count
8	Framed-IP-Address	52	Acct-Input-Gigawords
9	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
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

The RADIUS protocol features excellent extensibility. The Vendor-Specific attribute (attribute 26) allows a vendor to define extended attributes. The extended attributes can implement functions that the standard RADIUS protocol does not provide.

A vendor can encapsulate multiple subattributes in the TLV format in attribute 26 to provide extended functions. As shown in Figure 5, a subattribute encapsulated in attribute 26 consists of the following parts:

· Vendor-ID—ID of the vendor. The most significant byte is 0. The other three bytes contains a code compliant to RFC 1700. The vendor ID of H3C is 25506.

· Vendor-Type—Type of the subattribute.

· Vendor-Length—Length of the subattribute.

· Vendor-Data—Contents of the subattribute.

For more information about the proprietary RADIUS subattributes of H3C, see "H3C proprietary RADIUS subattributes."

Figure 5 Format of attribute 26

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 server 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, such as using a client/server model, using shared keys for data encryption, and providing flexibility and scalability. Table 3 lists the primary differences between HWTACACS and RADIUS.

Table 3 Primary differences between HWTACACS and RADIUS

HWTACACS	RADIUS
Uses TCP, which provides reliable network transmission.	Uses UDP, which provides high 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's roles and authorization. A user can use only commands that are permitted by the user roles and authorized by the HWTACACS server.	Does not support authorization of configuration commands. Access to commands solely depends on the user's roles. For more information about user roles, see Fundamentals Configuration Guide.

Basic HWTACACS packet exchange process

Figure 6 describes how HWTACACS performs user authentication, authorization, and accounting for a Telnet user.

Figure 6 Basic HWTACACS packet exchange process for a Telnet user

HWTACACS operates using in 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.

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. If the authentication succeeds, the HWTACACS server sends back an authentication response to indicate that the user has passed authentication.

12. The HWTACACS client sends a user authorization request packet to the HWTACACS server.

13. If the authorization succeeds, the HWTACACS server sends back an authorization response, indicating that the user is now authorized.

14. Knowing that the user is now authorized, the HWTACACS client pushes its CLI to the user and permits the user to log in.

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

The Lightweight Directory Access Protocol (LDAP) provides standard multiplatform directory service. LDAP was developed on the basis of the X.500 protocol. It improves the following functions of X.500:

· Read/write interactive access.

· Browse.

· Search.

LDAP is suitable for storing data that does not often change. The protocol is used to store user information. For example, LDAP server software Active Directory Server is used in Microsoft Windows operating systems. The software stores the user information and user group information for user login authentication and authorization.

LDAP directory service

LDAP uses directories to maintain the organization information, personnel information, 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 attributes are used to store information such as usernames, passwords, emails, computer names, and phone numbers.

LDAP uses a client/server model, and 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

AAA can use LDAP to provide authentication and authorization services for users. LDAP defines a set of operations to implement its functions. The main operations for authentication and authorization are the bind operation and search operation.

· The bind operation allows an LDAP client to perform the following operations:

? Establish a connection with the LDAP server.

? Obtain the access rights to the LDAP server.

? Check the validity of user information.

· The search operation constructs search conditions and obtains the directory resource information of the LDAP server.

In LDAP authentication, the client completes the following tasks:

1. Uses the LDAP server administrator DN to bind with the LDAP server. After the binding is created, the client establishes a connection to the server and obtains the right to search.

2. Constructs search conditions by using the username in the authentication information of a user. The specified root directory of the server is searched and a user DN list is generated.

3. Binds with the LDAP server by using each user DN and password. If a binding is created, the user is considered legal.

In LDAP authorization, the client performs the same tasks as in LDAP authentication. When the client constructs search conditions, it obtains both authorization information and the user DN list.

Basic LDAP authentication process

The following example illustrates the basic LDAP authentication process for a Telnet user.

Figure 7 Basic LDAP authentication process for a Telnet user

The following shows the basic LDAP authentication process:

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 right to search, 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 acknowledgment to the LDAP client.

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 might 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. The server will check 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 user's access request.

9. The LDAP client saves the user DN that has been bound and exchanges authorization packets with the authorization server.

? If LDAP authorization is used, see the authorization process shown in Figure 8.

? If another method is expected for authorization, the authorization process of that method applies.

10. After successful authorization, the LDAP client notifies the user of the successful login.

Basic LDAP authorization process

The following example illustrates the basic LDAP authorization process for a Telnet user.

Figure 8 Basic LDAP authorization process for a Telnet user

The following shows the basic LDAP authorization process:

1. A Telnet user initiates a connection request and sends the username and password to the device. The device will act as the LDAP client during authorization.

2. After receiving the request, the device exchanges authentication packets with the authentication server for the user:

? If LDAP authentication is used, see the authentication process shown in Figure 7.

- If the device (the LDAP client) uses the same LDAP server for authentication and authorization, skip to step 6.

- If the device (the LDAP client) uses different LDAP servers for authentication and authorization, skip to step 4.

? If another authentication method is used, the authentication process of that method applies. The device acts as the LDAP client. Skip to step 3.

3. The LDAP client establishes a TCP connection with the LDAP authorization server.

4. To obtain the right to search, the LDAP client uses the administrator DN and password to send an administrator bind request to the LDAP server.

5. The LDAP server processes the request. If the bind operation is successful, the LDAP server sends an acknowledgment to the LDAP client.

6. The LDAP client sends an authorization search request with the username of the Telnet user to the LDAP server. If the user uses the same LDAP server for authentication and authorization, the client sends the request with the saved user DN of the Telnet user to the LDAP server.

7. After receiving the request, the LDAP server searches for the user information by the base DN, search scope, filtering conditions, and LDAP attributes. If a match is found, the LDAP server sends a response to notify the LDAP client of the successful search.

8. After successful authorization, the LDAP client notifies the user of the successful login.

AAA implementation on the device

This section describes AAA user management and methods.

User management based on ISP domains and user access types

AAA manages users based on the users' ISP domains and access types.

On a NAS, each user belongs to one ISP domain. The NAS determines the ISP domain to which a user belongs based on the username entered by the user at login.

Figure 9 Determining the ISP domain for a user by username

AAA manages users in the same ISP domain based on the users' access types. The device supports the following user access types:

· LAN—LAN users must pass 802.1X or MAC authentication to come online.

· Login—Login users include SSH, Telnet, FTP, and terminal users that log in to the device. Terminal users can access through a console port.

· Portal—Portal users must pass portal authentication to access the network.

· PPP.

· IKE—IKE users must pass IKE extended authentication to access the network.

· Web—Web users log in to the Web interface of the device through HTTP or HTTPS.

NOTE:

The device also provides authentication modules (such as 802.1X) for implementation of user authentication management policies. If you configure these authentication modules, the ISP domains for users of the access types depend on the configuration of the authentication modules.

AAA methods

AAA supports configuring different authentication, authorization, and accounting methods for different types of users in an ISP domain. The NAS determines the ISP domain and access type of a user. The NAS also uses the methods configured for the access type in the domain to control the user's access.

AAA also supports configuring a set of default methods for an ISP domain. These default methods are applied to users for which no AAA methods are configured.

The device supports the following authentication methods:

· No authentication—This method trusts all users and does not perform authentication. For security purposes, do not use this method.

· Local authentication—The NAS authenticates users by itself, based on the locally configured user information including the usernames, passwords, and attributes. Local authentication allows high speed and low cost, but the amount of information that can be stored is limited by the size of the storage space.

· Remote authentication—The NAS works with a RADIUS, HWTACACS, or LDAP server to authenticate users. The server manages user information in a centralized manner. Remote authentication provides high capacity, reliable, and centralized authentication services for multiple NASs. You can configure backup methods to be used when the remote server is not available.

The device supports the following authorization methods:

· No authorization—The NAS performs no authorization exchange. The following default authorization information applies after users pass authentication:

? Non-login users can access the network.

? Login users obtain the level-0 user role. For more information about the level-0 user role, see RBAC configuration in Fundamentals Configuration Guide.

? The working directory for FTP, SFTP, and SCP login users is the root directory of the NAS. However, the users do not have permission to access the root directory.

· Local authorization—The NAS performs authorization according to the user attributes locally configured for users.

· Remote authorization—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 packet. HWTACACS authorization is separate from HWTACACS authentication, and the authorization information is included in the authorization response after successful authentication. You can configure backup methods to be used when the remote server is not available.

The device supports the following accounting methods:

· No accounting—The NAS does not perform accounting for the users.

· Local accounting—Local accounting is implemented on the NAS. It counts and controls the number of concurrent users that use the same local user account, but does not provide statistics for charging.

· Remote accounting—The NAS works with a RADIUS server or HWTACACS server for accounting. You can configure backup methods to be used when the remote server is not available.

In addition, the device provides the following login services to enhance device security:

· Command authorization—Enables the NAS to let the authorization server determine whether a command entered by a login user is permitted. Login users can execute only commands permitted by the authorization server. For more information about command authorization, see Fundamentals Configuration Guide.

· Command accounting—When command authorization is disabled, command accounting enables the accounting server to record all valid commands executed on the device. When command authorization is enabled, command accounting enables the accounting server to record all authorized commands. For more information about command accounting, see Fundamentals Configuration Guide.

· User role authentication—Authenticates each user that wants to obtain another user role without logging out or getting disconnected. For more information about user role authentication, see Fundamentals Configuration Guide.

Protocols and standards

· 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 5176, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)

· RFC 1492, An Access Control Protocol, Sometimes Called TACACS

· RFC 1777, Lightweight Directory Access Protocol

· RFC 2251, Lightweight Directory Access Protocol (v3)

RADIUS attributes

Commonly used standard RADIUS attributes

No.	Attribute	Description
1	User-Name	Name of the user to be authenticated.
2	User-Password	User password for PAP authentication, only present in Access-Request packets when PAP authentication is used.
3	CHAP-Password	Digest of the user password for CHAP authentication, only present in Access-Request packets when CHAP authentication is used.
4	NAS-IP-Address	IP address for the server to use to identify the client. Typically, a client is identified by the IP address of its access interface. This attribute is only present in Access-Request packets.
5	NAS-Port	Physical port of the NAS that the user accesses.
6	Service-Type	Type of service that the user has requested or type of service to be provided.
7	Framed-Protocol	Encapsulation protocol for framed access.
8	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, this attribute can be used to define the maximum size of EAP packets allowed to be processed in 802.1X EAP authentication.
14	Login-IP-Host	IP address of the NAS interface that the user accesses.
15	Login-Service	Type of 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 cause 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 subattributes.
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 H3C device, this attribute includes the MAC address of the user.
32	NAS-Identifier	Identification that the NAS uses to identify itself to the RADIUS server.
40	Acct-Status-Type	Type of the Accounting-Request packet. Possible values include: · 1—Start. · 2—Stop. · 3—Interim-Update. · 4—Reset-Charge. · 7—Accounting-On. (Defined in the 3rd Generation Partnership Project.) · 8—Accounting-Off. (Defined in the 3rd Generation Partnership Project.) · 9 to 14—Reserved for tunnel accounting. · 15—Reserved for failed.
45	Acct-Authentic	Authentication method used by the user. Possible values include: · 1—RADIUS. · 2—Local. · 3—Remote.
60	CHAP-Challenge	CHAP challenge generated by the NAS for MD5 calculation during CHAP authentication.
61	NAS-Port-Type	Type of the physical port of the NAS that is authenticating the user. Possible values include: · 15—Ethernet. · 16—Any type of ADSL. · 17—Cable. (With cable for cable TV.) · 19—WLAN-IEEE 802.11. · 201—VLAN. · 202—ATM. 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.

H3C proprietary RADIUS subattributes

No.	Subattribute	Description
1	Input-Peak-Rate	Peak rate in the direction from the user to the NAS, in bps.
2	Input-Average-Rate	Average rate in the direction from the user to the NAS, in bps.
3	Input-Basic-Rate	Basic rate in the direction from the user to the NAS, in bps.
4	Output-Peak-Rate	Peak rate in the direction from the NAS to the user, in bps.
5	Output-Average-Rate	Average rate in the direction from the NAS to the user, in bps.
6	Output-Basic-Rate	Basic rate in the direction from the NAS to the user, in bps.
15	Remanent_Volume	Total amount of data available for the connection, in different units for different server types.
20	Command	Operation for the session, used for session control. Possible values include: · 1—Trigger-Request. · 2—Terminate-Request. · 3—SetPolicy. · 4—Result. · 5—PortalClear.
24	Control_Identifier	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 of a retransmitted packet must also include this attribute and the value of this attribute must be the same. For Accounting-Request packets of the start, stop, and interim update types, the Control_Identifier attribute does not take effect.
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, SFTP, or SCP user working directory. When the RADIUS client acts as the FTP, SFTP, or SCP server, this attribute is used to set the working directory for an FTP, SFTP, or SCP 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.
62	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 packets from the 802.1X user. This attribute only exists in Access-Accept and Accounting-Request packets.
111	Longitude-Latitude	Longitude and latitude information of the NAS.
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.

AAA configuration considerations and task list

To configure AAA, complete the following tasks on the NAS:

1. Configure the required AAA schemes:

? Local authentication—Configure local users and the related attributes, including the usernames and passwords, for the users to be authenticated.

? Remote authentication—Configure the required RADIUS, HWTACACS, and LDAP schemes.

2. Configure AAA methods for the users' ISP domains. Remote AAA methods need to use the configured RADIUS, HWTACACS, and LDAP schemes.

Figure 10 AAA configuration procedure

To configure AAA, perform the following tasks:

Tasks at a glance
(Required.) Perform a minimum one of the following tasks to configure local users or AAA schemes: · Configuring local users · Configuring RADIUS schemes · Configuring HWTACACS schemes · Configuring LDAP schemes
(Required.) Configure AAA methods for ISP domains: 1. (Required.) Creating an ISP domain 2. (Optional.) Configuring ISP domain attributes 3. (Required.) Perform a minimum one of the following tasks to configure AAA authentication, authorization, and accounting methods for the ISP domain: ? Configuring authentication methods for an ISP domain ? Configuring authorization methods for an ISP domain ? Configuring accounting methods for an ISP domain
(Optional.) Configuring the RADIUS session-control feature
(Optional.) Configuring the RADIUS DAS feature
(Optional.) Changing the DSCP priority for RADIUS packets
(Optional.) Setting the maximum number of concurrent login users
(Optional.) Configuring local BYOD authorization
(Optional.) Configuring and applying an ITA policy
(Optional.) Configuring a NAS-ID profile

Configuring AAA schemes

This section includes information on configuring local users, RADIUS schemes, HWTACACS schemes, and LDAP schemes.

Configuring local users

To implement local authentication, authorization, and accounting, 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 the combination of a username and a user type. Local users are classified into the following types:

· Device management user—User that logs in to the device for device management.

· Network access user—User that accesses network resources through the device. Network access users also include guests that access the network temporarily. Guests can use LAN and portal services.

The following shows the configurable local user attributes:

· Description—Descriptive information of the user.

· 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, HTTP, HTTPS, IKE, LAN access, portal, PPP, SSH, Telnet, and terminal.

· User state—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.

· Upper limit of concurrent logins using the same user name—Maximum number of users that can concurrently access the device by using the same user name. When the number reaches the upper limit, no more local users can access the device by using the user name.

· User group—Each local user belongs to a local user group and has all attributes of the group. The attributes include the authorization attributes and password control attributes. For more information about local user group configuration, see "Configuring user group attributes."

· 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. For support and usage information about binding attributes, see "Configuring local user attributes."

· Authorization attributes—Authorization attributes indicate the user's rights after it passes local authentication. For support information about authorization attributes, see "Configuring local user attributes."

Configure the authorization attributes based on the service type of local users. For example, you do not need to configure the FTP/SFTP/SCP working directory attribute for a PPP user.

You can configure an authorization attribute in user group view or local user view. The setting of an authorization attribute in local user view takes precedence over the attribute setting in user group view.

? The attribute configured in user group view takes effect on all local users in the user group.

? The attribute configured in local user view takes effect only on the local user.

· Password control attributes—Password control attributes help control password security for device management users. Password control attributes include password aging time, minimum password length, password composition checking, password complexity checking, and login attempt limit.

You can configure a password control attribute in system view, user group view, or local user view. 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."

Local user configuration task list

Tasks at a glance
(Required.) Configuring local user attributes
(Optional.) Configuring user group attributes
(Optional.) Configuring local guest attributes
(Optional.) Managing local guests
(Optional.) Displaying and maintaining local users and local user groups

Configuring local user attributes

When you configure local user attributes, follow these guidelines:

· When you use the password-control enable command to globally enable the password control feature, local user passwords are not displayed.

· You can configure authorization attributes and password control attributes in local user view or user group view. The setting in local user view takes precedence over the setting in user group view.

· Configure the location binding attribute based on the service types of users.

? For 802.1X users, specify the 802.1X-enabled Layer 2 Ethernet interfaces through which the users access the device.

? For MAC authentication users, specify the MAC authentication-enabled Layer 2 Ethernet interfaces through which the users access the device.

? For portal users, specify the portal-enabled interfaces through which the users access the device. Specify the Layer 2 Ethernet interfaces if portal is enabled on VLAN interfaces and the portal roaming enable command is not configured.

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 [ class { manage \| network } ]	By default, no local users exist.
3. (Optional.) Configure a password for the local user.	· For a network access user: password { cipher \| simple } string · For a device management user: password [ { hash \| simple } string ]	No password is configured for a local user. A local user can pass authentication after entering the correct username and passing attribute checks.
4. Assign services to the local user.	· For a network access user: service-type { ike \| lan-access \| portal \| ppp } · For a device management user: service-type { ftp \| { http \| https \| ssh \| telnet \| terminal } * }	By default, no services are authorized to a local user.
5. (Optional.) Place the local user in the active or blocked state.	state { active \| block }	By default, a local user is in active state and can request network services.
6. (Optional.) Set the upper limit of concurrent logins using the local user name.	access-limit max-user-number	By default, the number of concurrent logins is not limited for the local user. This command takes effect only when local accounting is configured for the local user. It does not apply to FTP, SFTP, or SCP users. These users do not support accounting.
7. (Optional.) Configure binding attributes for the local user.	bind-attribute { call-number call-number [ : subcall-number ] \| ip ip-address \| location interface interface-type interface-number \| mac mac-address \| vlan vlan-id } *	By default, no binding attributes are configured for a local user.
8. (Optional.) Configure authorization attributes for the local user.	authorization-attribute { acl acl-number \| callback-number callback-number \| idle-cut minute \| ip ipv4-address \| ip-pool ipv4-pool-name \| ipv6 ipv6-address \| ipv6-pool ipv6-pool-name \| ipv6-prefix ipv6-prefix prefix-length \| { primary-dns \| secondary-dns } { ip ipv4-address \| ipv6 ipv6-address } \| session-timeout minutes \| url url-string \| user-profile profile-name \| user-role role-name \| vlan vlan-id \| work-directory directory-name } *	The following default settings apply: · The working directory for FTP, SFTP, and SCP users is the root directory of the NAS. However, the users do not have permission to access the root directory. · The network-operator user role is assigned to local users that are created by a network-admin or level-15 user.
9. (Optional.) Configure password control attributes for the local user.	· Set the password aging time: password-control aging aging-time · Set the minimum password length: password-control length length · Configure the password composition policy: password-control composition type-number type-number [ type-length type-length ] · Configure the password complexity checking policy: password-control complexity { same-character \| user-name } check · Configure the maximum login attempts and the action to take if there is a login failure: password-control login-attempt login-times [ exceed { lock \| lock-time time \| unlock } ]	By default, the local user uses password control attributes of the user group to which the local user belongs. Only device management users support the password control feature.
10. (Optional.) Assign the local user to a user group.	group group-name	By default, a local user belongs to user group system.
11. (Optional.) Configure a description for the local user.	description text	By default, no description is configured for a local user. You can configure descriptions only for network access users.

Configuring user group attributes

User groups simplify local user configuration and management. A user group contains 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. Local user attributes that are manageable include authorization attributes and password control 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 user group attributes:

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	By default, a system-defined user group exists. The group name is system.
3. Configure authorization attributes for the user group.	authorization-attribute { acl acl-number \| callback-number callback-number \| idle-cut minute \| ipv6-pool ipv6-pool-name \| ipv6-prefix ipv6-prefix prefix-length \| { primary-dns \| secondary-dns } { ip ipv4-address \| ipv6 ipv6-address } \| session-timeout minutes \| url url-string \| user-profile profile-name \| vlan vlan-id \| work-directory directory-name } *	By default, no authorization attributes are configured for a user group.
4. (Optional.) Configure password control attributes for the user group.	· Set the password aging time: password-control aging aging-time · Set the minimum password length: password-control length length · Configure the password composition policy: password-control composition type-number type-number [ type-length type-length ] · Configure the password complexity checking policy: password-control complexity { same-character \| user-name } check · Configure the maximum login attempts and the action to take for login failures: password-control login-attempt login-times [ exceed { lock \| lock-time time \| unlock } ]	By default, the user group uses the global password control settings. For more information, see "Configuring password control."

Configuring local guest attributes

Create local guests and configure guest attributes to control temporary network access behavior. Guests can access the network after passing local authentication. You can configure the recipient addresses and send attribute information to the local guests and guest sponsors by email.

To configure local guest attributes:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a local guest and enter local guest view.	local-user user-name class network guest	By default, no local guests exist.
3. Configure a password for the local guest.	password { cipher \| simple } string	By default, no password is configured for a local guest.
4. Configure a description for the local guest.	description text	By default, no description is configured for a local guest.
5. Specify the name of the local guest.	full-name name-string	By default, no name is specified for a local guest.
6. Specify the company of the local guest.	company company-name	By default, no company is specified for a local guest.
7. Specify the phone number of the local guest.	phone phone-number	By default, no phone number is specified for a local guest.
8. Specify the email address of the local guest.	email email-string	By default, no email address is specified for a local guest. The device sends email notifications to this address to inform the guest of the account information.
9. Specify the sponsor name for the local guest.	sponsor-full-name name-string	By default, no sponsor name is specified for a local guest.
10. Specify the sponsor department for the local guest.	sponsor-department department-string	By default, no sponsor department is specified for a local guest.
11. Specify the sponsor email address for the local guest.	sponsor-email email-string	By default, no sponsor email address is specified for a local guest. The device sends email notifications to this address to inform the sponsor of the guest information.
12. Configure the validity period for the local guest.	validity-datetime start-date start-time to expiration-date expiration-time	By default, a local guest does not expire. Expired guests cannot pass local authentication.
13. Assign the local guest to a user group.	group group-name	By default, a local guest belongs to user group system.

Managing local guests

The local guest management features are for registration, approval, maintenance, and access control of local guests.

The device provides the following local guest management features:

· Guest auto-delete—The device regularly checks the validity status of each local guest and automatically deletes expired local guests.

· Registration and approval—The device creates local guests after the guest registration information is approved by a guest manager.

· Email notification—The device notifies the local guests, guest sponsors, or guest managers by email of the guest account information or guest registration requests.

· Local guest creation in batch—Create a batch of local guests.

· Local guest import—Import guest account information from a .csv file to create local guests on the device based on the imported information.

· Local guest export—Export local guest account information to a .csv file. You can import the account information to other devices as needed.

The registration and approval processes are as follows:

1. The device pushes the portal user registration page to a user that wants to access the network as a local guest.

2. The user submits account information for registration, including the user name, password, and email address.

3. The device forwards the registration request to the guest manager in an email notification.

4. The guest manager adds supplementary information as needed and approves the registration information.

The guest manager must process the registration request before the waiting-approval timeout timer expires. The device automatically deletes expired registration request information.

5. The device creates a local guest account and sends an email notification to the user and guest sponsor. The email contains local guest account, password, validity period, and other account information.

The user can access the network as a local guest.

To manage local guests:

Step	Command	Remarks
1. Enter system view	system-view	N/A
2. Configure the subject and body of email notifications.	local-guest email format to { guest \| manager \| sponsor } { body body-string \| subject sub-string }	By default, no subject and body are configured.
3. Configure the email sender address in the email notifications sent by the device for local guests.	local-guest email sender email-address	By default, no email sender address is configured for the email notifications sent by the device.
4. Specify an SMTP server for sending email notifications of local guests.	local-guest email smtp-server url-string	By default, no SMTP server is specified.
5. Configure the guest manager's email address.	local-guest manager-email email-address	By default, the guest manager's email address is not configured.
6. (Optional.) Set the waiting-approval timeout timer for guest registration requests.	local-guest timer waiting-approval time-value	The default is 24 hours.
7. (Optional.) Import guest account information from a .csv file in the specified path to create local guests based on the imported information.	local-user-import class network guest url url-string validity-datetime start-date start-time to expiration-date expiration-time [ auto-create-group \| override \| start-line line-number ] *	N/A
8. (Optional.) Create local guests in batch.	local-guest generate username-prefix name-prefix [ password-prefix password-prefix ] suffix suffix-number [ group group-name ] count user-count validity-datetime start-date start-time to expiration-date expiration-time	Batch generated local guests share the same name prefix. You can also configure a password prefix to be shared by the guests.
9. (Optional.) Export local guest account information to a .csv file in the specified path.	local-user-export class network guest url url-string	N/A
10. (Optional.) Enable the guest auto-delete feature.	local-guest auto-delete enable	By default, the guest auto-delete feature is disabled.
11. Return to user view.	quit	N/A
12. Send email notifications to the local guest or the guest sponsor.	local-guest send-email user-name user-name to { guest \| sponsor }	The email contents include the user name, password, and validity period of the guest account.

Displaying and maintaining local users and local user groups

Execute display commands in any view.

Task	Command
Display the local user configuration and online user statistics.	display local-user [ class { manage \| network [ guest ] } \| idle-cut { disable \| enable } \| service-type { ftp \| http \| https \| ike \| lan-access \| portal \| ppp \| ssh \| telnet \| terminal } \| state { active \| block } \| user-name user-name class { manage \| network [ guest ] } \| vlan vlan-id ]
Display the user group configuration.	display user-group { all \| name group-name [ byod-authorization ] }
Display pending registration requests for local guests.	display local-guest waiting-approval [ user-name user-name ]
Clear pending registration requests for local guests.	reset local-guest waiting-approval [ user-name user-name ]

Configuring RADIUS schemes

A RADIUS scheme specifies the RADIUS servers that the device can work with and defines a set of parameters. The device uses the parameters to exchange information with the RADIUS servers, including the server IP addresses, UDP port numbers, shared keys, and server types.

Configuration task list

Tasks at a glance
(Optional.) Configuring a test profile for RADIUS server status detection
(Required.) Creating a RADIUS scheme
(Required.) Specifying the RADIUS authentication servers
(Optional.) 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 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.) Setting RADIUS timers
(Optional.) Configuring the accounting-on feature
(Optional.) Interpreting the RADIUS class attribute as CAR parameters
(Optional.) Configuring the Login-Service attribute check method for SSH, FTP, and terminal users
(Optional.) Setting the data measurement unit for the Remanent_Volume attribute
(Optional.) Configuring the MAC address format for RADIUS attribute 31
(Optional.) Enabling SNMP notifications for RADIUS
(Optional.) Displaying and maintaining RADIUS

Configuring a test profile for RADIUS server status detection

Use a test profile to detect whether a RADIUS authentication server is reachable at a detection interval. To detect the RADIUS server status, you must configure the RADIUS server to use this test profile in a RADIUS scheme.

With the test profile specified, the device sends a detection packet to the RADIUS server within each detection interval. The detection packet is a simulated authentication request that includes the specified user name in the test profile.

· If the device receives a response from the server within the interval, it sets the server to the active state.

· If the device does not receive any response from the server within the interval, it sets the server to the blocked state.

The device refreshes the RADIUS server status at each detection interval according to the detection result.

The device stops detecting the status of the RADIUS server when one of the following operations is performed:

· The RADIUS server is removed from the RADIUS scheme.

· The test profile configuration is removed for the RADIUS server in RADIUS scheme view.

· The test profile is deleted.

· The RADIUS server is manually set to the blocked state.

· The RADIUS scheme is deleted.

To configure a test profile for RADIUS server status detection:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Configure a test profile for detecting the status of RADIUS authentication servers.	radius-server test-profile profile-name username name [ interval interval ]	By default, no test profiles exist. You can configure multiple test profiles in the system.

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Configure a test profile for detecting the status of RADIUS authentication servers.

radius-server test-profile profile-name username name [ interval interval ]

By default, no test profiles exist.

You can configure multiple test profiles in the system.

Creating a RADIUS scheme

Create a RADIUS scheme before performing any other RADIUS configurations. You can configure a maximum of 16 RADIUS schemes. A RADIUS scheme can be used by multiple ISP domains.

To create a RADIUS scheme:

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

Specifying the RADIUS authentication servers

A RADIUS authentication server completes authentication and authorization together, because authorization information is piggybacked in authentication responses sent to RADIUS clients.

You can specify one primary authentication server and a maximum of 16 secondary authentication servers for a RADIUS scheme. Secondary servers provide AAA services when the primary server becomes unavailable. The device searches for an active server in the order the secondary servers are configured.

If redundancy is not required, specify only the primary server. A RADIUS authentication server can function as the primary authentication server for one scheme and a secondary authentication server for another scheme at the same time.

To specify RADIUS authentication 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
3. Specify RADIUS authentication servers.	· Specify the primary RADIUS authentication server: primary authentication { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| test-profile profile-name ] * · Specify a secondary RADIUS authentication server: secondary authentication { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| test-profile profile-name ] *	By default, no authentication servers are specified. To support server status detection, specify an existing test profile for the RADIUS authentication server. If the test profile does not exist, the device cannot detect the server status. Two authentication servers in a scheme, primary or secondary, cannot have the same combination of IP address and port number.

Specifying the RADIUS accounting servers and the relevant parameters

You can specify one primary accounting server and a maximum of 16 secondary accounting servers for a RADIUS scheme. Secondary servers provide AAA services when the primary server becomes unavailable. The device searches for an active server in the order the secondary servers are configured.

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

The device sends a stop-accounting request to the accounting server in the following situations:

· The device receives a connection teardown request from a host.

· The device receives a connection teardown command from an administrator.

When the maximum number of real-time accounting attempts is reached, the device disconnects users that have no accounting responses.

RADIUS does not support accounting for FTP, SFTP, and SCP users.

To specify RADIUS accounting servers and the relevant parameters 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 RADIUS accounting servers.	· Specify the primary RADIUS accounting server: primary accounting { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string ] * · Specify a secondary RADIUS accounting server: secondary accounting { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string ] *	By default, no accounting servers are specified. Two accounting servers in a scheme, primary or secondary, cannot have the same combination of IP address and port number.
4. (Optional.) Set the maximum number of real-time accounting attempts.	retry realtime-accounting retries	The default setting is 5.

Specifying the shared keys for secure RADIUS communication

The RADIUS client and server use the MD5 algorithm and shared keys to generate the Authenticator value for packet authentication and user password encryption. The client and server must use the same key for each type of communication.

A key configured in this task is for all servers of the same type (accounting or authentication) in the scheme. The key has a lower priority than a key configured individually for a RADIUS server.

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
3. Specify a shared key for secure RADIUS communication.	key { accounting \| authentication } { cipher \| simple } string	By default, no shared key is specified for secure RADIUS authentication or accounting communication. The shared key configured on the device must be the same as the shared key configured on the RADIUS server.

Setting the username format and traffic statistics units

A username is in the userid@isp-name format, where the isp-name argument 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 of each username to be sent.

If two or more ISP domains use the same RADIUS scheme, configure the RADIUS scheme to keep the ISP domain name in usernames for domain identification.

The device reports online user traffic statistics in accounting packets. The traffic measurement units are configurable, but they must be the same as the traffic measurement units configured on the RADIUS accounting servers.

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
3. Set the format for usernames sent to the RADIUS servers.	user-name-format { keep-original \| with-domain \| without-domain }	By default, the ISP domain name is included in a username sent to a RADIUS server.
4. (Optional.) Set the data flow and packet measurement units for traffic statistics.	data-flow-format { data { byte \| giga-byte \| kilo-byte \| mega-byte } \| packet { giga-packet \| kilo-packet \| mega-packet \| one-packet } } *	By default, traffic is counted in bytes and packets.

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. A RADIUS request is retransmitted if the NAS does not receive a server response for the request within the response timeout timer. For more information about the RADIUS server response timeout timer, see "Setting RADIUS timers."

You can set the maximum number for the NAS to retransmit a RADIUS request to the same server. When the maximum number is reached, the NAS tries to communicate with other RADIUS 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.

To set the maximum number of RADIUS request transmission attempts:

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 retries	The default setting is 3.

Setting the status of RADIUS servers

To control the RADIUS 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. The secondary servers function as the backup of the primary server. The device chooses servers based on the following rules:

· When the primary server is in active state, the device communicates with the primary server.

· If the primary server fails, the device performs the following operations:

? Changes the server status to blocked.

? Starts a quiet timer for the server.

? Tries to communicate with a secondary server in active state that has the highest priority.

· If the secondary server is unreachable, the device performs the following operations:

? Changes the server status to blocked.

? Starts a quiet timer for the server.

? Tries to communicate with the next secondary server in active state that has the highest priority.

· The search process continues until the device finds an available secondary server or has checked all secondary servers in active state. If no server is available, the device considers the authentication or accounting attempt a failure.

· When the quiet timer of a server expires or you manually set the server to the active state, the status of the server changes back to active. The device does not check the server again during the authentication or accounting process.

· When you remove a server in use, communication with the server times out. The device looks for a server in active state by first checking the primary server, and then checking secondary servers in the order they are configured.

· When all servers are in blocked state, the device only tries to communicate with the primary server.

· When one or more servers are in active state, the device tries to communicate with these active servers only, even if the servers are unavailable.

· When a RADIUS server's status changes automatically, the device changes this server's status accordingly in all RADIUS schemes in which this server is specified.

· When a RADIUS server is manually set to blocked, server detection is disabled for the server, regardless of whether a test profile has been specified for the server. When the RADIUS server is set to active state, server detection is enabled for the server on which an existing test profile is specified.

By default, the device sets the status of all RADIUS servers to active. However, in some situations, you must 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:

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 status.	· Set the status of the primary RADIUS authentication server: state primary authentication { active \| block } · Set the status of the primary RADIUS accounting server: state primary accounting { active \| block } · Set the status of a secondary RADIUS authentication server: state secondary authentication [ { ipv4-address \| ipv6 ipv6-address } [ port-number ] * ] { active \| block } · Set the status of a secondary RADIUS accounting server: state secondary accounting [ { ipv4-address \| ipv6 ipv6-address } [ port-number ] * ] { active \| block }	By default, a RADIUS server is in active state. The configured server status cannot be saved to any configuration file, and can only be viewed by using the display radius scheme command. After the device restarts, all servers are restored to the active state.

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 a managed NAS.

· If it is the IP address of a managed NAS, the server processes the packet.

· If it is not the IP address of a managed NAS, 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.

You can specify a source IP address for outgoing RADIUS packets in RADIUS scheme view or in system view.

· The IP address specified in RADIUS scheme view applies only to one RADIUS scheme.

· The IP address specified in system view applies to 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.

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 { ipv4-address \| ipv6 ipv6-address }	By default, the primary IP address of the RADIUS packet outbound interface is used as the source IP address.

To specify a 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 source IP address for outgoing RADIUS packets.	nas-ip { ipv4-address \| ipv6 ipv6-address }	By default, the source IP address specified by using the radius nas-ip command in system view is used. If the source IP address is not specified, the primary IP address of the outbound interface is used.

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. The timer starts immediately after a RADIUS request is sent. If the device does not receive a 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 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 at which the device sends real-time accounting packets to the RADIUS accounting server for online users.

When you set RADIUS timers, follow these guidelines:

· Consider the number of secondary servers when you configure the maximum number of RADIUS packet transmission attempts and the RADIUS server response timeout timer. If the RADIUS scheme includes many secondary servers, the retransmission process might be too long and the client connection in the access module, such as Telnet, can time out.

· When the client connections have a short timeout period, a large number of secondary servers can cause the initial authentication or accounting attempt to fail. In this case, reconnect the client rather than adjusting the RADIUS packet transmission attempts and server response timeout timer. Typically, the next attempt will succeed, because the device has blocked the unreachable servers to shorten the time to find a reachable server.

· Make sure the server quiet timer is set correctly. A timer that is too short might result in frequent authentication or accounting failures. This is because the device will continue to attempt to communicate with an unreachable server that is in active state. A timer that is too long might temporarily block a reachable server that has recovered from a failure. This is because the server will remain in blocked state until the timer expires.

· A short real-time accounting interval helps improve accounting precision but requires many system resources. When there are 1000 or more users, set the interval to 15 minutes or longer.

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	The default setting is 3 seconds.
4. Set the quiet timer for the servers.	timer quiet minutes	The default setting is 5 minutes.
5. Set the real-time accounting timer.	timer realtime-accounting interval [ second ]	The default setting is 12 minutes.

Configuring the accounting-on feature

When the accounting-on feature is enabled, the device automatically sends an accounting-on packet to the RADIUS server after the entire device reboots. Upon receiving the accounting-on packet, the RADIUS server logs out all online users so they can log in again through the device. Without this feature, users cannot log in again after the reboot, because the RADIUS server considers them to come online.

You can configure the interval for which the device waits to resend the accounting-on packet and the maximum number of retries.

The extended accounting-on feature enhances the accounting-on feature in a distributed architecture. For the extended accounting-on feature to take effect, the RADIUS server must run on IMC and the accounting-on feature must be enabled.

The extended accounting-on feature is applicable to LAN and PPP users. The user data is saved to the IRF member devices through which the users access the system. When the extended accounting-on feature is enabled, the system automatically sends an accounting-on packet to the RADIUS server after a member device reboot (IRF fabric not entirely reboot). The packet contains the member device identifier. Upon receiving the accounting-on packet, the RADIUS server logs out all online users that access the system through the member device.

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.	accounting-on enable [ interval seconds \| send send-times ] *	By default, the accounting-on feature is disabled.
4. (Optional.) Enable extended accounting-on.	accounting-on extended	By default, extended accounting-on is disabled.

Interpreting the RADIUS class attribute as CAR parameters

A RADIUS server may deliver CAR parameters for user-based traffic monitoring and control by using the RADIUS class attribute (attribute 25) in RADIUS packets. You can configure the device to interpret the class attribute to CAR parameters.

To configure the device to interpret the RADIUS class attribute as CAR parameters:

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 RADIUS class attribute as CAR parameters.	attribute 25 car	By default, the RADIUS class attribute is not interpreted as CAR parameters.

Configuring the Login-Service attribute check method for SSH, FTP, and terminal users

The device supports the following check methods for the Login-Service attribute (RADIUS attribute 15) of SSH, FTP, and terminal users:

· Strict—Matches Login-Service attribute values 50, 51, and 52 for SSH, FTP, and terminal services, respectively.

· Loose—Matches the standard Login-Service attribute value 0 for SSH, FTP, and terminal services.

An Access-Accept packet received for a user must contain the matching attribute value. Otherwise, the user cannot log in to the device.

Use the loose check method only when the server does not issue Login-Service attribute values 50, 51, and 52 for SSH, FTP, and terminal users.

To configure the Login-Service attribute check method for SSH, FTP, and terminal users:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Configure the Login-Service attribute check method for SSH, FTP, and terminal users.	attribute 15 check-mode { loose \| strict }	The default check method is strict.

Setting the data measurement unit for the Remanent_Volume attribute

The RADIUS server uses the Remanent_Volume attribute in authentication or real-time accounting responses to notify the device of the current amount of data available for online users.

Perform this task to set the data measurement unit for the Remanent_Volume attribute. Make sure the configured measurement unit is the same as the user data measurement unit on the RADIUS server.

To set the data measurement unit for the Remanent_Volume attribute:

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 data measurement unit for the Remanent_Volume attribute.	attribute remanent-volume unit { byte \| giga-byte \| kilo-byte \| mega-byte }	By default, the data measurement unit is kilobyte.

Configuring the MAC address format for RADIUS attribute 31

RADIUS servers of different types might have different requirements for the MAC address format in RADIUS attribute 31. Configure the MAC address format for RADIUS attribute 31 to meet the requirements of the RADIUS servers.

To configure the MAC address format for RADIUS attribute 31:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter RADIUS scheme view.	radius scheme radius-scheme-name	N/A
3. Configure the MAC address format for RADIUS attribute 31.	attribute 31 mac-format section { six \| three } separator separator-character { lowercase \| uppercase }	By default, a MAC address is in the format of HH-HH-HH-HH-HH-HH. The MAC address is separated by hyphen (-) into six sections with letters in upper case.

Enabling SNMP notifications for RADIUS

When SNMP notifications are enabled for RADIUS, the SNMP agent supports the following notifications generated by RADIUS:

· RADIUS server unreachable notification—The RADIUS server cannot be reached. RADIUS generates this notification if it does not receive a response to an accounting or authentication request within the specified number of RADIUS request transmission attempts.

· RADIUS server reachable notification—The RADIUS server can be reached. RADIUS generates this notification for a previously blocked RADIUS server after the quiet timer expires.

· Excessive authentication failures notification—The number of authentication failures compared to the total number of authentication attempts exceeds the specified threshold.

For RADIUS SNMP notifications to be sent correctly, you must also configure SNMP on the device. For more information about SNMP configuration, see Network Management and Monitoring Configuration Guide.

To enable SNMP notifications for RADIUS:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable SNMP notifications for RADIUS.	snmp-agent trap enable radius [ accounting-server-down \| accounting-server-up \| authentication-error-threshold \| authentication-server-down \| authentication-server-up ] *	By default, all SNMP notifications are disabled for RADIUS.

Displaying and maintaining RADIUS

Execute display commands in any view and reset commands in user view.

Task	Command
Display the RADIUS scheme configuration.	display radius scheme [ radius-scheme-name ]
Display RADIUS packet statistics.	display radius statistics
Clear RADIUS statistics.	reset radius statistics

Configuring HWTACACS schemes

Configuration task list

Tasks at a glance
(Required.) Creating an HWTACACS scheme
(Required.) Specifying the HWTACACS authentication servers
(Optional.) Specifying the HWTACACS authorization servers
(Optional.) Specifying the HWTACACS accounting servers
(Required.) Specifying the shared keys for secure HWTACACS communication
(Optional.) 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

Creating an HWTACACS scheme

Create an HWTACACS scheme before performing any other HWTACACS configurations. You can configure a maximum of 16 HWTACACS schemes. An HWTACACS scheme can be used by multiple ISP domains.

To create an HWTACACS scheme:

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	By default, no HWTACACS schemes exist.

Specifying the HWTACACS authentication servers

You can specify one primary authentication server and a maximum of 16 secondary authentication servers for an HWTACACS scheme. When the primary server is not available, the device searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication.

If redundancy is not required, specify only the primary server. An HWTACACS server can function as the primary authentication server in one scheme and as the secondary authentication server in another scheme at the same time.

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
3. Specify HWTACACS authentication servers.	· Specify the primary HWTACACS authentication server: primary authentication { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| single-connection ] * · Specify a secondary HWTACACS authentication server: secondary authentication { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| single-connection ] *	By default, no authentication servers are specified. Two HWTACACS authentication servers in a scheme, primary or secondary, cannot have the same combination of IP address and port number.

Specifying the HWTACACS authorization servers

You can specify one primary authorization server and a maximum of 16 secondary authorization servers for an HWTACACS scheme. When the primary server is not available, the device searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication.

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.

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
3. Specify HWTACACS authorization servers.	· Specify the primary HWTACACS authorization server: primary authorization { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| single-connection ] * · Specify a secondary HWTACACS authorization server: secondary authorization { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| single-connection ] *	By default, no authorization servers are specified. Two HWTACACS authorization servers in a scheme, primary or secondary, cannot have the same combination of IP address and port number.

Specifying the HWTACACS accounting servers

You can specify one primary accounting server and a maximum of 16 secondary accounting servers for an HWTACACS scheme. When the primary server is not available, the device searches for the secondary servers in the order they are configured. The first secondary server in active state is used for communication.

If redundancy is not required, specify only the primary server. 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.

HWTACACS does not support accounting for FTP, SFTP, and SCP users.

To specify HWTACACS accounting 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
3. Specify HWTACACS accounting servers.	· Specify the primary HWTACACS accounting server: primary accounting { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| single-connection ] * · Specify a secondary HWTACACS accounting server: secondary accounting { ipv4-address \| ipv6 ipv6-address } [ port-number \| key { cipher \| simple } string \| single-connection ] *	By default, no accounting servers are specified. Two HWTACACS accounting servers in a scheme, primary or secondary, cannot have the same combination of IP address and port number.

Specifying the shared keys for secure HWTACACS communication

The HWTACACS client and server use the MD5 algorithm and shared keys to generate the Authenticator value for packet authentication and user password encryption. The client and server must use the same key for each type of communication.

Perform this task to configure shared keys for servers in an HWTACACS scheme. The keys take effect on all servers for which a shared key is not individually configured.

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
3. Specify a shared key for secure HWTACACS authentication, authorization, or accounting communication.	key { accounting \| authentication \| authorization } { cipher \| simple } string	By default, no shared key is specified for secure HWTACACS authentication, authorization, or accounting communication. The shared key configured on the device must be the same as the shared key configured on the HWTACACS server.

Setting the username format and traffic statistics units

A username is typically in the userid@isp-name format, where the isp-name argument represents the user's ISP domain name. By default, the ISP domain name is included in a username. If HWTACACS servers do not recognize usernames that contain ISP domain names, you can configure the device to send usernames without domain names to the servers.

If two or more ISP domains use the same HWTACACS scheme, configure the HWTACACS scheme to keep the ISP domain name in usernames for domain identification.

To set the username format and 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
3. Set the format of usernames sent to the HWTACACS servers.	user-name-format { keep-original \| with-domain \| without-domain }	By default, the ISP domain name is included in a username sent to an HWTACACS server.
4. (Optional.) Set the data flow and packet measurement units for traffic statistics.	data-flow-format { data { byte \| giga-byte \| kilo-byte \| mega-byte } \| packet { giga-packet \| kilo-packet \| mega-packet \| one-packet } } *	By default, traffic is counted in bytes and 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 IP address of a managed NAS, the server processes the packet.

· If it is not the IP address of a managed NAS, 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.

You can specify the source IP address for outgoing HWTACACS packets in HWTACACS scheme view or in system view.

· The IP address specified in HWTACACS scheme view applies to one HWTACACS scheme.

· The IP address specified in system view applies to 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 { ipv4-address \| ipv6 ipv6-address }	By default, the primary IP address of the HWTACACS packet outbound interface is used as the source IP address.

To specify a source IP address 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
3. Specify the source IP address of outgoing HWTACACS packets.	nas-ip { ipv4-address \| ipv6 ipv6-address }	By default, the source IP address specified by using the hwtacacs nas-ip command in system view is used. If the source IP address is not specified, the primary IP address of the outbound interface is used.

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 server response timeout timer. The device starts this timer immediately after an HWTACACS authentication, authorization, or accounting request is sent. If the device does not receive a response from the server within the timer, it sets the server to blocked. Then, the device sends the request to another HWTACACS server.

· Real-time accounting timer (realtime-accounting)—Defines the interval at which the device sends real-time accounting packets to the HWTACACS accounting server for online users.

· Server quiet timer (quiet)—Defines the duration to keep an unreachable server in blocked state. If a server is not reachable, the device changes the server 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.

The server quiet timer setting affects the status of HWTACACS servers. If the scheme includes one primary HWTACACS server and multiple secondary HWTACACS servers, the device communicates with the HWTACACS servers based on the following rules:

· When the primary server is in active state, the device communicates with the primary server.

· If the primary server fails, the device performs the following operations:

? Changes the server status to blocked.

? Starts a quiet timer for the server.

? Tries to communicate with a secondary server in active state that has the highest priority.

· If the secondary server is unreachable, the device performs the following operations:

? Changes the server status to blocked.

? Starts a quiet timer for the server.

? Tries to communicate with the next secondary server in active state that has the highest priority.

· When the quiet timer of a server expires, the status of the server changes back to active. The device does not check the server again during the authentication, authorization, or accounting process.

· When all servers are in blocked state, the device only tries to communicate with the primary server.

· When one or more servers are in active state, the device tries to communicate with these servers only, even if they are unavailable.

· When an HWTACACS server's status changes automatically, the device changes this server's status accordingly in all HWTACACS schemes in which this server is specified.

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.	timer response-timeout seconds	By default, the HWTACACS server response timeout timer is 5 seconds.
4. Set the real-time accounting interval.	timer realtime-accounting minutes	By default, the real-time accounting interval is 12 minutes. A short interval helps improve accounting precision but requires many system resources. When there are 1000 or more users, set a longer interval.
5. Set the server quiet timer.	timer quiet minutes	By default, the server quiet timer is 5 minutes.

Displaying and maintaining HWTACACS

Execute display commands in any view and reset commands in user view.

Task	Command
Display the configuration or server statistics of HWTACACS schemes.	display hwtacacs scheme [ hwtacacs-scheme-name [ statistics ] ]
Clear HWTACACS statistics.	reset hwtacacs statistics { accounting \| all \| authentication \| authorization }

Configuring LDAP schemes

Configuration task list

Tasks at a glance
Configuring an LDAP server: · (Required.) Creating an LDAP server · (Required.) Configuring the IP address of the LDAP server · (Optional.) Specifying the LDAP version · (Optional.) Setting the LDAP server timeout period · (Required.) Configuring administrator attributes · (Required.) Configuring LDAP user attributes
(Optional.) Configuring an LDAP attribute map
(Required.) Creating an LDAP scheme
(Required.) Specifying the LDAP authentication server
(Optional.) Specifying the LDAP authorization server
(Optional.) Specifying an LDAP attribute map for LDAP authorization
(Optional.) Displaying and maintaining LDAP

Creating an LDAP server

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an LDAP server and enter LDAP server view.	ldap server server-name	By default, no LDAP servers exist.

Configuring the IP address of the LDAP server

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter LDAP server view.	ldap server server-name	N/A
3. Configure the IP address of the LDAP server.	{ ip ip-address \| ipv6 ipv6-address } [ port port-number ]	By default, an LDAP server does not have an IP address. You can configure either an IPv4 address or an IPv6 address for an LDAP server. The most recent configuration takes effect.

Specifying the LDAP version

Specify the LDAP version on the NAS. The device supports LDAPv2 and LDAPv3. The LDAP version specified on the device must be consistent with the version specified on the LDAP server.

To specify the LDAP version:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter LDAP server view.	ldap server server-name	N/A
3. Specify the LDAP version.	protocol-version { v2 \| v3 }	By default, LDAPv3 is used. A Microsoft LDAP server supports only LDAPv3.

Setting the LDAP server timeout period

If the device sends a bind or search request to an LDAP server without receiving the server's response within the server timeout period, the authentication or authorization request times out. Then, the device tries the backup authentication or authorization method. If no backup method is configured in the ISP domain, the device considers the authentication or authorization attempt a failure.

To set the LDAP server timeout period:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter LDAP server view.	ldap server server-name	N/A
3. Set the LDAP server timeout period.	server-timeout time-interval	By default, the 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 server view.	ldap server server-name	N/A
3. Specify the administrator DN.	login-dn dn-string	By default, no administrator DN is specified. The administrator DN specified on the device must be the same as the administrator DN configured on the LDAP server.
4. Configure the administrator password.	login-password { cipher \| simple } string	By default, no administrator password is specified.

Configuring LDAP user attributes

To authenticate a user, an LDAP client must complete the following operations:

1. Establish a connection to the LDAP server.

2. Obtain the user DN from the LDAP server.

3. Use the user DN and the user's password to bind with the LDAP server.

LDAP provides a DN search mechanism for obtaining the user DN. According to the 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.

· Username attribute.

· Username format.

· User object class.

If the LDAP server contains many directory levels, a user DN search starting from the root directory can take a long time. To improve efficiency, you can change the start point by specifying the search base DN.

To configure LDAP user attributes:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter LDAP server view.	ldap server server-name	N/A
3. Specify the user search base DN.	search-base-dn base-dn	By default, no user search base DN is specified.
4. (Optional.) Specify the user search scope.	search-scope { all-level \| single-level }	By default, the user search scope is all-level.
5. (Optional.) Specify the username attribute.	user-parameters user-name-attribute { name-attribute \| cn \| uid }	By default, the username attribute is cn.
6. (Optional.) Specify the username format.	user-parameters user-name-format { with-domain \| without-domain }	By default, the username format is without-domain.
7. (Optional.) 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 for this command varies by server model.

Configuring an LDAP attribute map

Configure an LDAP attribute map to define a list of LDAP-AAA attribute mapping entries. To apply the LDAP attribute map, specify the name of the LDAP attribute map in the LDAP scheme used for authorization.

The LDAP attribute map feature enables the device to convert LDAP attributes obtained from an LDAP authorization server to device-recognizable AAA attributes based on the mapping entries. Because the device ignores unrecognized LDAP attributes, configure the mapping entries to include important LDAP attributes that should not be ignored.

An LDAP attribute can be mapped only to one AAA attribute. Different LDAP attributes can be mapped to the same AAA attribute.

To configure an LDAP attribute map:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an LDAP attribute map and enter LDAP attribute map view.	ldap attribute-map map-name	By default, no LDAP attribute maps exist.
3. Configure a mapping entry.	map ldap-attribute ldap-attribute-name [ prefix prefix-value delimiter delimiter-value ] aaa-attribute { user-group \| user-profile }	By default, an LDAP attribute map does not have any mapping entries. Repeat this command to configure multiple mapping entries.

Creating an LDAP scheme

You can configure a maximum of 16 LDAP schemes. An LDAP scheme can be used by multiple ISP domains.

To create an LDAP scheme:

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

Specifying 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 server-name	By default, no LDAP authentication server is specified.

Specifying 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 server-name	By default, no LDAP authorization server is specified.

Specifying an LDAP attribute map for LDAP authorization

Specify an LDAP attribute map for LDAP authorization to convert LDAP attributes obtained from the LDAP authorization server to device-recognizable AAA attributes.

You can specify only one LDAP attribute map in an LDAP scheme.

To specify an LDAP attribute map for LDAP authorization:

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 an LDAP attribute map.	attribute-map map-name	By default, no LDAP attribute map is specified.

Displaying and maintaining LDAP

Execute display commands in any view.

Task	Command
Display the configuration of LDAP schemes.	display ldap scheme [ ldap-scheme-name ]

Configuring AAA methods for ISP domains

You configure AAA methods for an ISP domain by specifying configured AAA schemes in ISP domain view. Each ISP domain has a set of system-defined AAA methods, which are local authentication, local authorization, and local accounting. If you do not configure any AAA methods for an ISP domain, the device uses the system-defined AAA methods for users in the domain.

AAA is available to login users after you enable scheme authentication for the users. For more information about the login authentication modes, see Fundamentals Configuration Guide.

Configuration prerequisites

To use local authentication for users in an ISP domain, configure local user accounts on the device first. See "Configuring local user attributes."

To use remote authentication, authorization, and accounting, create the required RADIUS, HWTACACS, or LDAP schemes. For more information about the scheme configuration, see "Configuring RADIUS schemes," "Configuring HWTACACS schemes," and "Configuring LDAP schemes."

Creating an ISP domain

In a networking scenario with multiple ISPs, the device can connect to users of different ISPs. These users can have different user attributes, such as different username and password structures, different service types, and different rights. To manage users of different ISPs, configure AAA methods and domain attributes for each ISP domain as needed.

The device supports a maximum of 16 ISP domains, including the system-defined ISP domain system. You can specify one of the ISP domains as the default domain.

On the device, each user belongs to an ISP domain. If a user does not provide an 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:

1. The authentication domain specified for the access module.

2. The ISP domain in the username.

3. The default ISP domain of the device.

If the chosen domain does not exist on the device, the device searches for the ISP domain that accommodates users assigned to nonexistent domains. If no such ISP domain is configured, user authentication fails.

NOTE:

Support for the authentication domain configuration depends on the access module. You can specify an authentication domain for 802.1X, portal, or MAC authentication.

When you configure an ISP domain, follow these restrictions and guidelines:

· An ISP domain cannot be deleted when it is the default ISP domain. Before you use the undo domain command, change the domain to a non-default ISP domain by using the undo domain default enable command.

· You can modify the settings of the system-defined ISP domain system, but you cannot delete the domain.

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	By default, a system-defined ISP domain exists. The domain name is system.
3. Return to system view.	quit	N/A
4. (Optional.) Specify the default ISP domain.	domain default enable isp-name	By default, the default ISP domain is ISP domain system.
5. (Optional.) Specify the ISP domain to accommodate users that are assigned to nonexistent domains.	domain if-unknown isp-domain-name	By default, no ISP domain is specified to accommodate users that are assigned to nonexistent domains.

Configuring ISP domain attributes

Overview

In an ISP domain, you can configure the following attributes:

· Domain status—By placing the ISP domain in active or blocked state, you allow or deny network service requests from users in the domain.

· Authorization attributes—The device assigns the authorization attributes in the ISP domain to the authenticated users that do not receive these attributes from the server. However, if the idle cut attribute is configured in the ISP domain, the device assigns the attribute to the authenticated users. If no idle cut attribute is configured in the ISP domain, the device uses the idle cut attribute assigned by the server. The device supports the following authorization attributes:

? Authorization ACL—The device restricts authenticated users to access only the network resources permitted by the ACL. For portal users, the authorization ACL can be configured in a preauthentication domain to authorize access to network resources before users pass authentication.

? Idle cut—It enables the device to check the traffic of each online user in the domain at the idle timeout interval. The device logs out an online user if the user's total traffic in the idle timeout period is less than the specified minimum traffic.

? IPv4 address pool—The device assigns IPv4 addresses from the pool to authenticated portal or PPP users in the domain.

? Default authorization user profile—When a user passes authentication, it typically obtains an authorization user profile from the local or remote server. If the user does not obtain any user profile, the device authorizes the default user profile of the ISP domain to the user. The device will restrict the user's behavior based on the profile. For portal users, the authorization user profile can be configured in a preauthentication domain to restrict user behaviors before users pass authentication.

? Session timeout timer—The device logs off a user when the user's session timeout timer expires.

? Authorization IPv6 address prefix—The device authorizes the IPv6 address prefix to authenticated PPP users in the domain.

? IPv6 address pool—The device assigns IPv6 addresses from the pool to authenticated portal or PPP users in the domain.

? DNS server address—The attribute specifies the DNS server that offers DNS services to the authenticated PPP users in the domain.

? Redirect URL—The device redirects PPP users in the domain to the URL after they pass authentication.

? Authorization user group—Authenticated users in the domain obtain all attributes of the user group.

? Maximum number of multicast groups—The attribute restricts the maximum number of multicast groups that an authenticated portal or PPP user can join concurrently.

· User online duration including idle timeout period—If a user goes offline due to connection failure or malfunction, the user's online duration sent to the server includes the idle timeout period authorized by the server. The online duration that is generated on the server is longer than the actual online duration of the user.

For portal users, the idle timeout period set by using the portal [ ipv6 ] user-detect command takes priority over the idle timeout period authorized by the server.

· ITA policy—The attribute allows the device to perform accounting at different charge rates for user data based on destination addresses. The ITA policy assigned from an AAA server takes precedence over the ITA policy in an ISP domain.

· Types of IP addresses that users rely on to use the basic services—A PPPoE user cannot come online if it does not obtain IP addresses of all the specified types for the basic services.

· DHCPv6 request timeout timer—The maximum period that the device waits for DHCPv6 to assign an IP address to a PPPoE user after the device finishes IPv6CP negotiation with the user.

Configuration procedure

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 in 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. Configure authorization attributes for authenticated users in the ISP domain.	authorization-attribute { acl acl-number \| idle-cut minute [ flow ] \| igmp max-access-number number \| ip-pool pool-name \| ipv6-pool ipv6-pool-name \| ipv6-prefix ipv6-prefix prefix-length \| mld max-access-number number \| { primary-dns \| secondary-dns } { ip ipv4-address \| ipv6 ipv6-address } \| session-timeout minutes \| url url-string \| user-group user-group-name \| user-profile profile-name }	By default, no authorization attributes are configured and the idle cut feature is disabled.
5. Configure the device to include the idle timeout period in the user online duration to be sent to the server.	session-time include-idle-time	By default, the user online duration sent to the server excludes the idle timeout period.
6. Specify the user address type in the ISP domain.	user-address-type { ds-lite \| ipv6 \| nat64 \| private-ds \| private-ipv4 \| public-ds \| public-ipv4 }	By default, no user address type is specified.
7. Specify the service type for users in the ISP domain.	service-type { hsi \| stb \| voip }	By default, the service type is hsi.
8. Apply an ITA policy to users in the ISP domain.	ita-policy policy-name	By default, no ITA policy is applied to an ISP domain.
9. Specify the types of IP addresses that PPPoE users must rely on to use the basic services.	basic-service-ip-type { ipv4 \| ipv6 \| ipv6-pd } *	By default, PPPoE users do not rely on any types of IP addresses to use the basic services.
10. Set the DHCPv6 request timeout timer for PPPoE users.	dhcpv6-follow-ipv6cp timeout delay-time	By default, the DHCPv6 request timeout timer for PPPoE users is 60 seconds.

Configuring authentication methods for an ISP domain

Configuration prerequisites

Before configuring authentication methods, complete the following tasks:

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

2. Determine whether to configure the default authentication method for all access types or service types. The default authentication method applies to all access users. However, the method has a lower priority than the authentication method that is specified for an access type or service type.

Configuration guidelines

When configuring authentication methods, follow these guidelines:

· If the authentication method uses a RADIUS scheme and the authorization method does not use 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.

· If an HWTACACS scheme is specified, the device uses the entered username for role authentication. If a RADIUS scheme is specified, the device uses the username $enabn$ on the RADIUS server for role authentication. The variable n represents a user role level. For more information about user role authentication, see Fundamentals Configuration Guide.

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 default authentication methods for all types of users.	authentication default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] \| ldap-scheme ldap-scheme-name [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }	By default, the default authentication method is local.
4. Specify extended authentication methods for IKE users.	authentication ike { local [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default authentication methods are used for IKE extended authentication.
5. Specify authentication methods for LAN users.	authentication lan-access { ldap-scheme ldap-scheme-name [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default authentication methods are used for LAN users.
6. Specify authentication methods for login users.	authentication login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] \| ldap-scheme ldap-scheme-name [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }	By default, the default authentication methods are used for login users.
7. Specify authentication methods for portal users.	authentication portal { ldap-scheme ldap-scheme-name [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default authentication methods are used for portal users.
8. Specify authentication methods for PPP users.	authentication ppp { local [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default authentication methods are used for PPP users.
9. Specify authentication methods for obtaining a temporary user role.	authentication super { hwtacacs-scheme hwtacacs-scheme-name \| radius-scheme radius-scheme-name } *	By default, the default authentication methods are used for obtaining a temporary user role.

Configuring authorization methods for an ISP domain

Configuration prerequisites

Before configuring authorization methods, complete the following tasks:

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

2. Determine whether to configure the default authorization method for all access types or service types. The default authorization method applies to all access users. However, the method has a lower priority than the authorization method that is specified for an access type or service type.

Configuration guidelines

When configuring authorization methods, follow these guidelines:

· The device supports HWTACACS authorization but not LDAP authorization.

· To use a RADIUS scheme as the authorization method, specify the name of the RADIUS scheme that is configured as the authentication method for the ISP domain. If an invalid RADIUS scheme is specified as the authorization method, RADIUS authentication and authorization fail.

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 default authorization methods for all types of users.	authorization default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }	By default, the authorization method is local.
4. Specify command authorization methods.	authorization command { hwtacacs-scheme hwtacacs-scheme-name [ local ] [ none ] \| local [ none ] \| none }	By default, the default authorization methods are used for command authorization.
5. Specify authorization methods for IKE extended authentication.	authorization ike { local [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default authorization methods are used for IKE extended authentication.
6. Specify authorization methods for LAN users.	authorization lan-access { local [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default authorization methods are used for LAN users.
7. Specify authorization methods for login users.	authorization login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }	By default, the default authorization methods are used for login users.
8. Specify authorization methods for portal users.	authorization portal { local [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default authorization methods are used for portal users.
9. Specify authorization methods for PPP users.	authorization ppp { local [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default authorization methods are used for PPP users.

Configuring accounting methods for an ISP domain

Configuration prerequisites

Before configuring accounting methods, complete the following tasks:

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

2. Determine whether to configure the default accounting method for all access types or service types. The default accounting method applies to all access users. However, the method has a lower priority than the accounting method that is specified for an access type or service type.

Configuration guidelines

When configuring accounting methods, follow these guidelines:

· FTP, SFTP, and SCP users do not support accounting.

· Local accounting does not provide statistics for charging. It only counts and controls the number of concurrent users that use the same local user account. The threshold is configured by using the access-limit command.

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
3. Specify default accounting methods for all types of users.	accounting default { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }	By default, the accounting method is local.
4. Specify the command accounting method.	accounting command hwtacacs-scheme hwtacacs-scheme-name	By default, the default accounting methods are used for command accounting.
5. Specify accounting methods for LAN users.	accounting lan-access { broadcast radius-scheme radius-scheme-name1 radius-scheme radius-scheme-name2 [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default accounting methods are used for LAN users.
6. Specify accounting methods for login users.	accounting login { hwtacacs-scheme hwtacacs-scheme-name [ radius-scheme radius-scheme-name ] [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ hwtacacs-scheme hwtacacs-scheme-name ] [ local ] [ none ] }	By default, the default accounting methods are used for login users.
7. Specify accounting methods for portal users.	accounting portal { broadcast radius-scheme radius-scheme-name1 radius-scheme radius-scheme-name2 [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default accounting methods are used for portal users.
8. Specify accounting methods for PPP users.	accounting ppp { broadcast radius-scheme radius-scheme-name1 radius-scheme radius-scheme-name2 [ local ] [ none ] \| local [ none ] \| none \| radius-scheme radius-scheme-name [ local ] [ none ] }	By default, the default accounting methods are used for PPP users.
9. Configure access control for users that encounter accounting-start failures.	accounting start-fail { offline \| online }	By default, the device allows users that encounter accounting-start failures to stay online.
10. Configure access control for users that have failed all their accounting-update attempts.	accounting update-fail { [ max-times times ] offline \| online }	By default, the device allows users that have failed all their accounting-update attempts to stay online.
11. Configure access control for users that have used up their data quotas.	accounting quota-out { offline \| online }	By default, the device logs off users that have used up their data quotas.

Configuring the RADIUS session-control feature

Enable this feature for the RADIUS server to dynamically change the user authorization information or forcibly disconnect users by using session-control packets. This task enables the device to receive RADIUS session-control packets on UDP port 1812.

To verify the session-control packets sent from a RADIUS server, specify the RADIUS server as a session-control client to the device.

When you configure the RADIUS session-control feature, follow these restrictions and guidelines:

· The RADIUS session-control feature can only work with RADIUS servers running on IMC.

· The session-control client configuration takes effect only when the session-control feature is enabled.

· The IP and shared key settings of a session-control client must be the same as the corresponding settings of the RADIUS server.

To configure the RADIUS session-control feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the session-control feature.	radius session-control enable	By default, the session-control feature is disabled.
3. Specify a session-control client.	radius session-control client { ip ipv4-address \| ipv6 ipv6-address } [ key { cipher \| simple } string ] *	By default, no session-control clients are specified.

Configuring the RADIUS DAS feature

Dynamic Authorization Extensions (DAE) to RADIUS, defined in RFC 5176, can log off online users or change their authorization information. DAE uses the client/server model.

In a RADIUS network, the RADIUS server typically acts as the DAE client (DAC) and the NAS acts as the DAE server (DAS).

When the RADIUS DAS feature is enabled, the NAS performs the following operations:

1. Listens to the default or specified UDP port to receive DAE requests.

2. Logs off online users that match the criteria in the requests, or changes their authorization information.

3. Sends DAE responses to the DAC.

DAE defines the following types of packets:

· Disconnect Messages (DMs)—The DAC sends DM requests to the DAS to log off specific online users.

· Change of Authorization Messages (CoA Messages)—The DAC sends CoA requests to the DAS to change the authorization information of specific online users.

To configure the RADIUS DAS feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the RADIUS DAS feature and enter RADIUS DAS view.	radius dynamic-author server	By default, the RADIUS DAS feature is disabled.
3. Specify a RADIUS DAC.	client { ip ipv4-address \| ipv6 ipv6-address } [ key { cipher \| simple } string ] *	By default, no RADIUS DACs are specified.
4. Specify the RADIUS DAS port.	port port-number	By default, the RADIUS DAS port is 3799.

Changing the DSCP priority for RADIUS packets

The DSCP priority in the ToS field determines the transmission priority of RADIUS packets. A larger value represents a higher priority.

To change the DSCP priority for RADIUS packets:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Change the DSCP priority for RADIUS packets.	radius [ ipv6 ] dscp dscp-value	By default, the DSCP priority is 0 for RADIUS packets.

Setting the maximum number of concurrent login users

Perform this task to set the maximum number of concurrent users that can log on to the device through a specific protocol, regardless of their authentication methods. The authentication methods include no authentication, local authentication, and remote authentication.

To set the maximum number of concurrent login users:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the maximum number of concurrent login users.	aaa session-limit { ftp \| http \| https \| ssh \| telnet } max-sessions	By default, the maximum number of concurrent login users is 32 for each user type.

Configuring local BYOD authorization

Use this feature to control authentication and authorization of Bring Your Own Device (BYOD) users based on account information, endpoint information, and access scenarios. After users pass local authentication, they obtain BYOD authorization attributes from the user group they are assigned to. A user group can contain different authorization attributes specific to the endpoint types of the users.

Configuring BYOD endpoint identification rules

A BYOD endpoint identification rule defines the mapping between an endpoint type and a fingerprint string. The device obtains fingerprint information from the authentication request of an endpoint, and matches the fingerprint with the rules for the associated endpoint type.

BYOD authorization supports the following endpoint fingerprints:

· DHCP Option 55 fingerprint—Parameter request list option. The option is used by an endpoint to request specified configuration parameters.

· HTTP user agent fingerprint—Located in the header of HTTP requests to carry information about the endpoint operating system, Web browser, and versions.

· MAC address fingerprint—OUI of the endpoint or MAC address range to which the endpoint belongs.

A fingerprint string can match only one endpoint type. However, an endpoint type can be associated with multiple fingerprint strings. You can use the byod rule-order command to specify the fingerprint types supported by the device and their match priority order.

The system has predefined BYOD endpoint identification rules. You can also configure BYOD endpoint identification rules depending on the network requirements.

To configure a BYOD endpoint identification rule:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Configure a BYOD endpoint identification rule.	byod rule { dhcp-option option-string \| http-user-agent agent-string \| mac-address mac-address mask mac-mask } device-type type-name	By default, only predefined BYOD endpoint identification rules exist.
3. Specify the supported BYOD endpoint identification rule types and their priority order.	byod rule-order { dhcp-option \| http-user-agent \| mac-address } *	By default, the device uses the following types of BYOD endpoint identification rules to match an endpoint type and the priority order is as follows: 4. DHCP Option 55-based rules. 5. HTTP user agent-based rules. 6. MAC address-based rules.

Configuring BYOD endpoint type-specific authorization attributes

BYOD authorization attributes in a user group are configured based on endpoint types to control users that have passed local authentication. After the device identifies the endpoint type of a user, it assigns BYOD authorization attributes matching the endpoint type in the user group of the user.

The device supports endpoint type-specific BYOD authorization only for network access users. For a user, an endpoint type-specific authorization attribute takes precedence over the same common authorization attribute specified for the user. A common authorization attribute specified for the user takes precedence over the same common authorization attribute specified for the user group to which the user belongs.

To configure endpoint type-specific BYOD authorization attributes:

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	By default, a user group named system exists on the device.
3. Configure authorization attributes for a type of BYOD endpoints in the user group.	byod authorization device-type type-name { acl acl-number \| callback-number callback-number \| idle-cut minutes \| ip-pool ipv4-pool-name \| ipv6-pool ipv6-pool-name \| ipv6-prefix ipv6-prefix prefix-length \| { primary-dns \| secondary-dns } { ip ipv4-address \| ipv6 ipv6-address } \| session-timeout minutes \| url url-string \| user-profile profile-name \| vlan vlan-id } *	By default, no authorization attributes are configured for any type of BYOD endpoints.

Displaying and maintaining local BYOD authorization

Execute display commands in any view.

Task	Command
Display BYOD endpoint identification rules.	display byod rule { dhcp-option [ option-string ] \| http-user-agent [ agent-string ] \| mac-address [ mac-address ] }
Display BYOD authorization information for a user group.	display user-group name group-name byod-authorization
Display the supported types of BYOD endpoint identification rules and their priority order.	display byod rule-order

Configuring and applying an ITA policy

Intelligent Target Accounting (ITA) provides a flexible accounting solution for users that request services of different charge rates. By defining different traffic levels based on the destination addresses of users' traffic, you can use ITA to separate the traffic accounting statistics of different levels for each user.

ITA services are supported only for portal and PPP users.

You must deploy an ITA policy to implement ITA services.

To deploy an ITA policy, perform the following tasks:

1. Configure a QoS policy to remark traffic destined for different IP addresses or subnets to different levels. For more information about QoS, see ACL and QoS Configuration Guide.

2. Configure a user profile, and apply the QoS policy to the user profile. For more information about user profiles, see "Configure user profiles."

3. Authorize the user profile to authenticated users. The following methods are available:

? Use a remote server or configure the device to assign the user profile.

? Specify the user profile in the authentication domain.

The user profile assigned by a remote server or the device takes precedence over the user profile specified in the authentication domain.

4. Configure an ITA policy, which includes the accounting methods, traffic levels, and access control for users that have used up their ITA data quotas.

5. Apply the ITA policy to authenticated users. The following methods are available:

? Use a RADIUS server to assign the ITA policy.

? Specify the ITA policy in the authentication domain.

The ITA policy assigned by a RADIUS server takes precedence over the ITA policy specified in the authentication domain.

You can configure accounting methods for an ITA policy. ITA accounting is separated from accounting of other services. However, you can configure the device to include the amount of ITA traffic in the overall traffic statistics sent to the accounting server.

To configure and apply an ITA policy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an ITA policy and enter ITA policy view.	ita policy policy-name	By default, no ITA policies exist.
3. Specify the accounting method in the ITA policy.	accounting-method { none \| radius-scheme radius-scheme-name [ none ] }	By default, the accounting method is none.
4. Specify a traffic level for ITA accounting.	accounting-level level { ipv4 \| ipv6 }	By default, no traffic levels are specified for ITA accounting.
5. (Optional.) Enable accounting merge.	accounting-merge enable	By default, accounting merge is disabled.
6. (Optional.) Configure access control for users that have used up their ITA data quotas.	traffic-quota-out { offline \| online }	By default, the users cannot access the authorized IP subnets after they use up their ITA data quotas.
7. (Optional.) Exclude the amount of ITA traffic from the overall traffic statistics that are sent to the accounting server.	traffic-separate enable	By default, the amount of ITA traffic is included in the overall traffic statistics that are sent to the accounting server.

Configuring a NAS-ID profile

By default, the device sends its device name in the NAS-Identifier attribute of all RADIUS requests.

A NAS-ID profile enables you to send different NAS-Identifier attribute strings in RADIUS requests from different VLANs. The strings can be organization names, service names, or any user categorization criteria, depending on the administrative requirements.

For example, map the NAS-ID companyA to all VLANs of company A. The device will send companyA in the NAS-Identifier attribute for the RADIUS server to identify requests from any Company A users.

You can apply a NAS-ID profile to portal- or port security-enabled interfaces. For more information, see "Configuring portal authentication" and "Configuring port security."

A NAS-ID can be bound with more than one VLAN, but a VLAN can be bound with only one NAS-ID.

To configure a NAS-ID profile:

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	By default, no NAS-ID profiles exist.
3. Configure a NAS-ID and VLAN binding in the profile.	nas-id nas-identifier bind vlan vlan-id	By default, no NAS-ID and VLAN bindings exist.

Displaying and maintaining AAA

Execute display commands in any view.

Task	Command
Display the configuration of ISP domains.	display domain [ isp-name ]

AAA configuration examples

AAA for SSH users by an HWTACACS server

Network requirements

As shown in Figure 11, configure the AC to meet the following requirements:

· Use the HWTACACS server for SSH user authentication, authorization, and accounting.

· Assign the default user role network-operator to SSH users after they pass authentication.

· Exclude domain names from the usernames sent to the HWTACACS server.

· Use expert as the shared keys for secure HWTACACS communication.

Figure 11 Network diagram

Configuration procedure

1. Configure the HWTACACS server:

# Set the shared keys to expert for secure communication with the AC. (Details not shown.)

# Add an account for the SSH user and specify the password. (Details not shown.)

2. Configure the AC:

# Configure IP addresses for the interfaces. (Details not shown.)

# Create an HWTACACS scheme.

<AC> system-view

[AC] hwtacacs scheme hwtac

# Specify the primary authentication server.

[AC-hwtacacs-hwtac] primary authentication 10.1.1.1 49

# Specify the primary authorization server.

[AC-hwtacacs-hwtac] primary authorization 10.1.1.1 49

# Specify the primary accounting server.

[AC-hwtacacs-hwtac] primary accounting 10.1.1.1 49

# Set the shared keys to expert in plaintext form for secure HWTACACS communication.

[AC-hwtacacs-hwtac] key authentication simple expert

[AC-hwtacacs-hwtac] key authorization simple expert

[AC-hwtacacs-hwtac] key accounting simple expert

# Exclude domain names from the usernames sent to the HWTACACS server.

[AC-hwtacacs-hwtac] user-name-format without-domain

[AC-hwtacacs-hwtac] quit

# Create an ISP domain named bbb and configure the domain to use the HWTACACS scheme for authentication, authorization, and accounting of login users.

[AC-isp-bbb] authentication login hwtacacs-scheme hwtac

[AC-isp-bbb] authorization login hwtacacs-scheme hwtac

[AC-isp-bbb] accounting login hwtacacs-scheme hwtac

[AC-isp-bbb] quit

# Create local RSA and DSA key pairs.

[AC] public-key local create rsa

[AC] public-key local create dsa

# Enable the SSH service.

[AC] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 31.

[AC] line vty 0 31

[AC-line-vty0-31] authentication-mode scheme

[AC-line-vty0-31] quit

# Enable the default user role feature to assign authenticated SSH users the default user role network-operator.

[AC] role default-role enable

Verifying the configuration

# Initiate an SSH connection to the AC, and enter the correct username and password. The user logs in to the AC. (Details not shown.)

# Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.)

Local authentication, HWTACACS authorization, and RADIUS accounting for SSH users

Network requirements

As shown in Figure 12, configure the AC to meet the following requirements:

· Perform local authentication for SSH servers.

· Use the HWTACACS server and RADIUS server for SSH user authorization and accounting, respectively.

· Exclude domain names from the usernames sent to the servers.

· Assign the default user role network-operator to SSH users after they pass authentication.

Configure an account named hello for the SSH user. Configure the shared keys to expert for secure communication with the HWTACACS server and RADIUS server.

Figure 12 Network diagram

Configuration procedure

1. Configure the HWTACACS server. (Details not shown.)

2. Configure the RADIUS server. (Details not shown.)

3. Configure the AC:

# Configure IP addresses for interfaces. (Details not shown.)

# Create local RSA and DSA key pairs.

<AC> system-view

[AC] public-key local create rsa

[AC] public-key local create dsa

# Enable the SSH service.

[AC] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 31.

[AC] line vty 0 31

[AC-line-vty0-31] authentication-mode scheme

[AC-line-vty0-31] quit

# Configure an HWTACACS scheme.

[AC] hwtacacs scheme hwtac

[AC-hwtacacs-hwtac] primary authorization 10.1.1.2 49

[AC-hwtacacs-hwtac] key authorization simple expert

[AC-hwtacacs-hwtac] user-name-format without-domain

[AC-hwtacacs-hwtac] quit

# Configure a RADIUS scheme.

[AC] radius scheme rd

[AC-radius-rd] primary accounting 10.1.1.1 1813

[AC-radius-rd] key accounting simple expert

[AC-radius-rd] user-name-format without-domain

[AC-radius-rd] quit

# Create a device management user.

[AC] local-user hello class manage

# Assign the SSH service to the local user.

[AC-luser-manage-hello] service-type ssh

# Set the password to 123456TESTplat&! in plaintext form for the local user.

[AC-luser-manage-hello] password simple 123456TESTplat&!

[AC-luser-manage-hello] quit

# Create an ISP domain named bbb and configure the login users to use local authentication, HWTACACS authorization, and RADIUS accounting.

[AC] domain bbb

[AC-isp-bbb] authentication login local

[AC-isp-bbb] authorization login hwtacacs-scheme hwtac

[AC-isp-bbb] accounting login radius-scheme rd

[AC-isp-bbb] quit

# Enable the default user role feature to assign authenticated SSH users the default user role network-operator.

[AC] role default-role enable

Verifying the configuration

# Initiate an SSH connection to the AC, and enter username hello@bbb and the correct password. The user logs in to the AC. (Details not shown.)

# Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.)

Authentication and authorization for SSH users by a RADIUS server

Network requirements

As shown in Figure 13, configure the AC to meet the following requirements:

· Use the RADIUS server for SSH user authentication and authorization.

· Include domain names in the usernames sent to the RADIUS server.

· Assign the default user role network-operator to SSH users after they pass authentication.

The RADIUS server runs on IMC. Add an account named hello@bbb on the RADIUS server.

The RADIUS server and the AC use expert as the shared key for secure RADIUS communication. The ports for authentication and accounting are 1812 and 1813, respectively.

Figure 13 Network diagram

Configuration procedure

1. Configure the RADIUS server on IMC 5.0:

NOTE:

In this example, the RADIUS server runs on IMC PLAT 5.0 (E0101) and IMC UAM 5.0 (E0101).

# Add the AC to IMC UAM as an access device:

Log in to IMC, click the Service tab, and select User Access Manager > Access Device Management > Access Device from the navigation tree. Then, click Add to configure an access device as follows:

a. Set the shared key to expert for secure RADIUS communication.

b. Set the ports for authentication and accounting to 1812 and 1813, respectively.

c. Select Device Management Service from the Service Type list.

d. Select H3C from the Access Device Type list.

e. Select an access device from the device list or manually add an access device. In this example, the device IP address is 10.1.1.2.

f. Use the default values for other parameters and click OK.

The IP address of the access device specified here must be the same as the source IP address of the RADIUS packets sent from the AC. The source IP address is chosen in the following order on the AC:

? IP address specified by using the nas-ip command.

? IP address specified by using the radius nas-ip command.

? IP address of the outbound interface (the default).

Figure 14 Adding the AC as an access device

# Add an account for device management:

Click the User tab, and select Access User View > Device Mgmt User from the navigation tree. Then, click Add to configure a device management account as follows:

a. Enter account name hello@bbb and specify the password.

b. Select SSH from the Service Type list.

c. Specify 10.1.1.0 to 10.1.1.255 as the IP address range of the hosts to be managed.

d. Click OK.

NOTE:

The IP address range must contain the IP address of the AC.

Figure 15 Adding an account for device management

2. Configure the AC:

# Configure IP addresses for interfaces. (Details not shown.)

# Create local RSA and DSA key pairs.

[AC] public-key local create rsa

[AC] public-key local create dsa

# Enable the SSH service.

[AC] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 31.

[AC] line vty 0 31

[AC-line-vty0-31] authentication-mode scheme

[AC-line-vty0-31] quit

# Enable the default user role feature to assign authenticated SSH users the default user role network-operator.

[AC] role default-role enable

# Create a RADIUS scheme.

[AC] radius scheme rad

# Specify the primary authentication server.

[AC-radius-rad] primary authentication 10.1.1.1 1812

# Set the shared key to expert in plaintext form for secure communication with the server.

[AC-radius-rad] key authentication simple expert

# Include domain names in the usernames sent to the RADIUS server.

[AC-radius-rad] user-name-format with-domain

[AC-radius-rad] quit

# Create an ISP domain named bbb and configure authentication, authorization, and accounting methods for login users.

[AC] domain bbb

[AC-isp-bbb] authentication login radius-scheme rad

[AC-isp-bbb] authorization login radius-scheme rad

[AC-isp-bbb] accounting login none

[AC-isp-bbb] quit

Verifying the configuration

# Initiate an SSH connection to the AC, and enter username hello@bbb and the correct password. The user logs in to the AC. (Details not shown.)

# Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.)

Authentication for SSH users by an LDAP server

Network requirements

As shown in Figure 16, the LDAP server uses domain ldap.com.

Configure the AC to meet the following requirements:

· Use the LDAP server to authenticate SSH users.

· Assign the default user role network-operator to SSH users after they pass authentication.

On the LDAP server, set the administrator password to admin!123456, add user aaa, and set the user's password to ldap!123456.

Figure 16 Network diagram

Configuration procedure

1. Configure the LDAP server:

NOTE:

In this example, the LDAP server runs Microsoft Windows 2003 Server Active Directory.

# Add a user named aaa and set the password to ldap!123456:

a. On the LDAP server, select Start > Control Panel > Administrative Tools.

b. Double-click Active Directory Users and Computers.

The Active Directory Users and Computers window is displayed.

c. From the navigation tree, click Users under the ldap.com node.

d. Select Action > New > User from the menu to display the dialog box for adding a user.

e. Enter logon name aaa and click Next.

Figure 17 Adding user aaa

f. In the dialog box, enter password ldap!123456, select options as needed, and click Next.

Figure 18 Setting the user's password

g. Click OK.

# Add user aaa to group Users:

a. From the navigation tree, click Users under the ldap.com node.

b. In the right pane, right-click user aaa and select Properties.

c. In the dialog box, click the Member Of tab and click Add.

Figure 19 Modifying user properties

d. In the Select Groups dialog box, enter Users in the Enter the object names to select field, and click OK.

User aaa is added to group Users.

Figure 20 Adding user aaa to group Users

# Set the administrator password to admin!123456:

a. In the right pane, right-click user Administrator and select Set Password.

b. In the dialog box, enter the administrator password. (Details not shown.)

2. Configure the AC:

# Configure the IP address of VLAN-interface 2 (the interface connected the AC to the LDAP server).

<AC> system-view

[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

# Create local RSA and DSA key pairs.

[AC] public-key local create rsa

[AC] public-key local create dsa

# Enable the SSH service.

[AC] ssh server enable

# Enable scheme authentication for user lines VTY 0 through VTY 31.

[AC] line vty 0 31

[AC-line-vty0-31] authentication-mode scheme

[AC-line-vty0-31] quit

# Enable the default user role feature to assign authenticated SSH users the default user role network-operator.

[AC] role default-role enable

# Configure an LDAP server.

[AC] ldap server ldap1

# Specify the IP address of the LDAP authentication server.

[AC-ldap-server-ldap1] ip 10.1.1.1

# Specify the administrator DN.

[AC-ldap-server-ldap1] login-dn cn=administrator,cn=users,dc=ldap,dc=com

# Specify the administrator password.

[AC-ldap-server-ldap1] login-password simple admin!123456

# Configure the base DN for user search.

[AC-ldap-server-ldap1] search-base-dn dc=ldap,dc=com

[AC-ldap-server-ldap1] quit

# Create an LDAP scheme.

[AC] ldap scheme ldap-shm1

# Specify the LDAP authentication server.

[AC-ldap-ldap-shm1] authentication-server ldap1

[AC-ldap-ldap-shm1] quit

# Create an ISP domain named bbb and configure authentication, authorization, and accounting methods for login users.

[AC] domain bbb

[AC-isp-bbb] authentication login ldap-scheme ldap-shm1

[AC-isp-bbb] authorization login none

[AC-isp-bbb] accounting login none

[AC-isp-bbb] quit

Verifying the configuration

# Initiate an SSH connection to the AC, and enter username aaa@bbb and password ldap!123456. The user logs in to the AC. (Details not shown.)

# Verify that the user can use the commands permitted by the network-operator user role. (Details not shown.)

AAA for 802.1X users by a RADIUS server

Network requirements

As shown in Figure 21, configure the AC to meet the following requirements:

· Use the RADIUS server for authentication, authorization, and accounting of 802.1X users.

· Include domain names in the usernames sent to the RADIUS server.

On the RADIUS server, perform the following tasks:

· Add a service that charges 120 dollars for up to 120 hours per month and assigns authenticated users to VLAN 4.

· Configure a user account named dot1x@bbb and assign the service to the user.

Set the shared keys to expert for secure RADIUS communication. Set the ports for authentication and accounting to 1812 and 1813, respectively.

Figure 21 Network diagram

Configuration procedure

1. Configure interfaces and VLANs, so the host promptly obtains a new IP address to access resources in the authorized VLAN after passing authentication. (Details not shown.)

2. Configure the RADIUS server:

NOTE:

In this section, the authentication and accounting RADIUS servers are IMC UAM 5.0 (E0101) and IMC CAMS 5.0 (E0101), respectively. They are running on IMC PLAT 5.0 (E0101).

# Add the AC to IMC UAM as an access device:

Log in to IMC, click the Service tab, and select User Access Manager > Access Device Management > Access Device from the navigation tree. Then, click Add to configure an access device as follows:

a. Set the shared key to expert for secure authentication and accounting communication.

b. Set the ports for authentication and accounting to 1812 and 1813, respectively.

c. Select LAN Access Service from the Service Type list.

d. Select H3C(General) from the Access Device Type list.

e. Select an access device from the device list or manually add an access device. In this example, the device IP address is 10.1.1.2.

f. Use the default values for other parameters and click OK.

The IP address of the access device specified here must be the same as the source IP address of the RADIUS packets sent from the AC. The source IP address is chosen in the following order on the AC:

? IP address specified by using the nas-ip command.

? IP address specified by using the radius nas-ip command.

? IP address of the outbound interface (the default).

Figure 22 Adding the AC as an access device

# Add a charging plan:

Click the Service tab, and select Accounting Manager > Charging Plans from the navigation tree to enter the charging plan configuration page. Then, click Add to configure a charging plan as follows:

a. Add a plan named UserAcct.

b. Select Flat rate from the Charging Template list.

c. Select time for Charge Based on, select Monthly for Billing Term, and enter 120 in the Fixed Fee field.

d. Enter 120 in the Usage Threshold field and select hr (hours) for the in field. The configuration allows the user to access the Internet for up to 120 hours per month.

e. Use the default values for other parameters and click OK.

Figure 23 Adding a charging plan

# Add a service:

Click the Service tab, and select User Access Manager > Service Configuration from the navigation tree. Then, click Add to configure a service as follows:

a. Add a service named Dot1x auth, and set the service suffix to bbb, the authentication domain for the 802.1X user. With the service suffix configured, you must configure the access device to send usernames that include domain names to the RADIUS server.

b. Select UserAcct from the Charging Plan list.

c. Select Deploy VLAN and set the ID of the VLAN to be assigned to 4.

d. Configure other parameters as needed.

e. Click OK.

Figure 24 Adding a service

# Add a user:

Click the User tab, and select Access User View > All Access Users from the navigation tree to enter the All Access Users page. Then, click Add to configure a user as follows:

a. Select the user or add a user named hello.

b. Specify the account name as dot1x and configure the password.

c. Select Dot1x auth in the Access Service area.

d. Configure other parameters as needed and click OK.

Figure 25 Adding an access user account

3. Configure the AC:

a. Configure a RADIUS scheme:

# Create a RADIUS scheme named rad and enter RADIUS scheme view.

<AC> system-view

[AC] radius scheme rad

# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.

[AC-radius-rad] primary authentication 10.1.1.1

[AC-radius-rad] primary accounting 10.1.1.1

[AC-radius-rad] key authentication simple expert

[AC-radius-rad] key accounting simple expert

# Include domain names in the usernames sent to the RADIUS server.

[AC-radius-rad] user-name-format with-domain

[AC-radius-rad] quit

b. Configure an authentication domain:

# Create an ISP domain named bbb and enter ISP domain view.

[AC] domain bbb

# Configure the ISP domain to use RADIUS scheme rad for authentication, authorization, and accounting of LAN users.

[AC-isp-bbb] authentication lan-access radius-scheme rad

[AC-isp-bbb] authorization lan-access radius-scheme rad

[AC-isp-bbb] accounting lan-access radius-scheme rad

[AC-isp-bbb] quit

c. Configure 802.1X authentication:

# Enable port security globally.

[AC] port-security enable

# Enable 802.1X EAP relay.

[AC] dot1x authentication-method eap

# Configure service template 1.

[AC] wlan service-template 1

# Set the SSID to sectest.

[AC-wlan-st-1] ssid sectest

# Bind VLAN 2 to the service template.

[AC-wlan-st-1] vlan 2

# Set the AKM mode to 802.1X.

[AC-wlan-st-1] akm mode dot1x

# Set the authentication mode to 802.1X.

[AC-wlan-st-1] client-security authentication-mode dot1x

# Specify the TKIP cipher suite, and enable the WPA IE in beacon and probe responses.

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

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

# Specify ISP domain bbb as the 802.1X authentication domain.

[AC-wlan-st-1] dot1x domain bbb

# Enable the service template.

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

# Create a manual AP named ap1, and specify the AP model and serial number.

[AC] wlan ap ap1 model WA536

[AC-wlan-ap-ap1] serial-id 219801A1NQB117012935

# Bind the service template to radio 1 of the AP.

[AC-wlan-ap-ap1] 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. On the host, use account dot1x@bbb to pass 802.1X authentication:

# If the host runs the Windows XP 802.1X client, configure the network connection properties as follows:

a. Click the Authentication tab of the properties window.

b. Select the Enable IEEE 802.1X authentication for this network option.

c. Select PEAP as the EAP type.

d. Click OK.

The user passes authentication after entering the correct username and password on the authentication page.

# If the host runs the iNode client, no advanced authentication options are required. The user can pass authentication after entering username dot1x@bbb and the correct password on the client property page.

2. Display 802.1X online user information.

[AC] display dot1x connection

User MAC address : 0015-e9a6-7cfe

AP name : ap1

Radio ID : 1

SSID : sectest

BSSID : 8434-9701-0b74

Username : dot1x@bbb

Authentication domain : bbb

Authentication method : EAP

Initial VLAN : 2

Authorization VLAN : 4

Authorization ACL number : N/A

Authorization user profile : N/A

Termination action : N/A

Session timeout period : N/A

Online from : 2015/06/01 17:15:46

Online duration : 0h 0m 14s

Total connections: 1

Local guest configuration and management

Network requirements

As shown in Figure 26, create a local guest named user1 for Jack. Configure local guest attributes and manage the local guest on the AC as follows:

· Configure attributes for the local guest, including the password, user group, validity period, and sponsor information.

· Enable the guest auto-delete feature.

· Specify an SMTP server and email sender address for the device to send local guest email notifications.

· Configure email addresses for the local guest, guest sponsor, and guest manager.

· Configure the subject and body of the email notifications to be sent to the guest, guest sponsor, and guest manager.

· Send email notifications of the local guest account information to the guest and guest sponsor.

Figure 26 Network diagram

Configuration procedure

1. Manage local guests:

# Enable the guest auto-delete feature for expired local guests.

<AC> system-view

[AC] local-guest auto-delete enable

# Specify an SMTP server to send local guest email notifications.

[AC] local-guest email smtp-server smtp://192.168.0.112/smtp

# Specify the email sender address as bbb@ccc.com in the email notifications sent by the device for local guests.

[AC] local-guest email sender bbb@ccc.com

# Specify the email address of the guest manager as guest-manager@ccc.com.

[AC] local-guest manager-email guest-manager@ccc.com

# Configure the subject and body of the email notifications to be sent to the local guest.

[AC] local-guest email format to guest subject Guest account information

[AC] local-guest email format to guest body A guest account has been created for your use. The username, password, and valid dates for the account are given below.

# Configure the subject and body of the email notifications to be sent to the guest sponsor.

[AC] local-guest email format to sponsor subject Guest account information

[AC] local-guest email format to sponsor body A guest account has been created for your use. The username, password, and valid dates for the account are given below.

# Configure the subject and body of the email notifications to be sent to the guest manager.

[AC] local-guest email format to manager subject Guest register information

[AC] local-guest email format to manager body A guest account has been registered. The username for the account is given below. Please approve the register information.

2. Configure the local guest:

# Create a user group named guest1.

[AC] user-group guest1

[AC-ugroup-guest1] quit

# Create a local guest named user1 and enter local guest view.

[AC] local-user user1 class network guest

# Set the guest password to 123456 in plaintext form.

[AC-luser-network(guest)-user1] password simple 123456

# Assign the guest to user group guest1.

[AC-luser-network(guest)-user1] group guest1

# Specify the name of the local guest.

[AC-luser-network(guest)-user1] fullname Jack

# Specify the company of the local guest.

[AC-luser-network(guest)-user1] company cc

# Configure the email address of the local guest.

[AC-luser-network(guest)-user1] email Jack@cc.com

# Configure the phone number of the local guest.

[AC-luser-network(guest)-user1] phone 131129237

# Configure a description for the local guest.

[AC-luser-network(guest)-user1] description A guest from company cc

# Configure the validity period of the local guest.

[AC-luser-network(guest)-user1] validity-datetime 2015/4/1 08:00:00 to 2015/4/3 18:00:00

# Specify the guest sponsor name as Sam.

[AC-luser-network(guest)-user1] sponsor-full-name Sam

# Configure the email address of the guest sponsor.

[AC-luser-network(guest)-user1] sponsor-email Sam@aa.com

# Configure the department of the guest sponsor as security.

[AC-luser-network(guest)-user1] sponsor-department security

[AC-luser-network(guest)-user1] quit

3. Configure the device to send guest email notifications:

# Send an email notification to the guest sponsor.

[AC] local-guest send-email user-name user1 to sponsor

# Send an email notification to the guest.

[AC] local-guest send-email user-name user1 to guest

Verifying the configuration

# Display local guest information.

[AC] display local-user user1 class network guest

Network access guest user user1:

State: Active

Service type: LAN access/Portal

User group: guest1

Full name: Jack

Company: cc

Email: Jack@cc.com

Phone: 131129237

Description: A guest from company cc

Sponsor full name: Sam

Sponsor department: security

Sponsor email: Sam@aa.com

Period of validity:

Start date and time: 2015/04/01-08:00:00

Expiration date and time:2015/04/03-18:00:00

# Verify that Jack can use username user1 and password 123456 to pass local authentication and come online during the validity period. (Details not shown.)

Troubleshooting RADIUS

RADIUS authentication failure

Symptom

User authentication always fails.

Analysis

Possible reasons include:

· A communication failure exists between the NAS and the RADIUS server.

· The username is not in the userid@isp-name format, 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

To resolve the problem:

1. Verify the following items:

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

2. If the problem persists, contact H3C Support.

RADIUS packet delivery failure

Symptom

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 and accounting UDP ports configured on the NAS are incorrect.

· The RADIUS server's authentication and accounting port numbers are being used by other applications.

Solution

To resolve the problem:

1. Verify the following items:

? The link between the NAS and the RADIUS server works well at both the physical and data link layers.

? The IP address of the RADIUS server is correctly configured on the NAS.

? The authentication and accounting UDP port numbers configured on the NAS are the same as those of the RADIUS server.

? The RADIUS server's authentication and accounting port numbers are available.

2. If the problem persists, contact H3C Support.

RADIUS accounting error

Symptom

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

To resolve the problem:

1. Verify the following items:

? The accounting port number is correctly configured.

? The accounting server IP address is correctly configured on the NAS.

2. If the problem persists, contact H3C Support.

Troubleshooting HWTACACS

Similar to RADIUS troubleshooting. See "Troubleshooting RADIUS."

Troubleshooting LDAP

LDAP authentication failure

Symptom

User authentication fails.

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 userid@isp-name format, 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 incorrect.

· The administrator DN or password is not configured.

· Some user attributes (for example, the username attribute) configured on the NAS are not consistent with those configured on the server.

· No user search base DN is specified for the LDAP scheme.

Solution

To resolve the problem:

1. Verify the following items:

? The NAS and the LDAP server can ping each other.

? The IP address and port number of the LDAP server configured on the NAS match those of the server.

? The username is in the correct format and the ISP domain for the user authentication 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) configured on the NAS are consistent with those configured on the LDAP server.

? The user search base DN for authentication is specified.

2. If the problem persists, contact H3C Support.

802.1X overview

802.1X is a port-based network access control protocol initially proposed for securing WLANs. The protocol 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. As shown in Figure 27, 802.1X authentication includes the following entities:

· Client (supplicant)—A user terminal seeking access to the LAN. The terminal must have 802.1X software to authenticate to the access device.

· Access device (authenticator)—Authenticates the client to control access to the LAN. In a typical 802.1X environment, the access device uses an authentication server to perform authentication.

· Authentication server—Provides authentication services for the access device. The authentication server first authenticates 802.1X clients by using the data sent from the access device. Then, the server returns the authentication results to the access device to make access decisions. The authentication server is typically a RADIUS server. In a small LAN, you can use the access device as the authentication server.

Figure 27 802.1X architecture

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.

· Uncontrolled port—Is always open to receive and transmit authentication packets.

· Controlled port—Filters packets depending on the port state.

? Authorized state—The controlled port is in authorized state when the client has passed authentication. The port allows traffic to pass through.

? Unauthorized state—The port is in unauthorized state when the client has failed authentication. The port controls traffic by using one of the following methods:

- Performs bidirectional traffic control to deny traffic to and from the client.

- Performs unidirectional traffic control to deny traffic from the client. The H3C devices support only unidirectional traffic control.

Figure 28 Authorization state of a controlled port

802.1X-related protocols

802.1X uses the Extensible Authentication Protocol (EAP) to transport authentication information for the client, the access device, and the authentication server. EAP is an authentication framework that uses the client/server model. The framework 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 access device over a wired or wireless LAN. Between the access device and the authentication server, 802.1X delivers authentication information by using 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."

Packet formats

EAP packet format

Figure 29 shows the EAP packet format.

Figure 29 EAP packet format

· Code—Type of the EAP packet. Options include Request (1), Response (2), Success (3), or Failure (4).

· Identifier—Used for matching Responses with Requests.

· Length—Length (in bytes) of the EAP packet. The EAP packet length is the sum of the Code, Identifier, Length, and Data fields.

· Data—Content of the EAP packet. This field appears only in a Request or Response EAP packet. The Data field contains the request type (or the response type) and the type data. Type 1 (Identity) and type 4 (MD5-Challenge) are two examples for the type field.

EAPOL packet format

Figure 30 shows the EAPOL packet format.

Figure 30 EAPOL packet format

· PAE Ethernet type—Protocol type. It takes the value 0x888E for EAPOL.

· Protocol version—The EAPOL protocol version used by the EAPOL packet sender.

· Type—Type of the EAPOL packet. Table 4 lists the types of EAPOL packets supported by H3C implementation of 802.1X.

Table 4 Types of EAPOL packets

Value	Type	Description
0x00	EAP-Packet	The client and the 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 access device.
0x02	EAPOL-Logoff	The client sends an EAPOL-Logoff message to tell the access device that the client is logging off.

· Length—Data 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 body—Content 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 31. 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 31 EAP-Message attribute format

Message-Authenticator

As shown in Figure 32, 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 32 Message-Authenticator attribute format

802.1X authentication initiation

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 the authentication server does not support the multicast address, you must use an 802.1X client that can send broadcast EAPOL-Start packets. For example, you can use the iNode 802.1X client.

Access device as the initiator

If the client cannot send EAPOL-Start packets, configure the access device to initiate authentication. One example is the 802.1X client available with Windows XP.

The access device supports the following modes:

· Multicast trigger mode—The access device multicasts EAP-Request/Identity packets to initiate 802.1X authentication at the identity request interval.

· Unicast trigger mode—Upon receiving a frame from an unknown MAC address, the access device sends an EAP-Request/Identity packet out of the receiving port to the MAC address. The device retransmits the packet if no response has been received within the identity request timeout interval. This process continues until the maximum number of request attempts set by using the dot1x retry command is reached.

The username request timeout timer sets both the identity request interval for the multicast trigger and the identity request timeout interval for the unicast trigger.

802.1X authentication procedures

802.1X authentication has two methods: EAP relay and EAP termination. You choose either mode depending on 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 33.

Figure 33 EAP relay

In EAP relay mode, the client must use the same authentication method as the RADIUS server. On the access device, you only need to use the dot1x authentication-method eap command to enable EAP relay.

· EAP termination mode.

As shown in Figure 34, the access device performs the following operations in EAP termination mode:

a. Terminates the EAP packets received from the client.

b. Encapsulates the client authentication information in standard RADIUS packets.

c. Uses PAP or CHAP to authenticate to the RADIUS server.

Figure 34 EAP termination

Comparing EAP relay and EAP termination

Packet exchange method

Benefits

Limitations

EAP relay

· Supports various EAP authentication methods.

· The configuration and processing are simple on the access device.

The RADIUS server must support the EAP-Message and Message-Authenticator attributes, and the EAP authentication method used by the client.

EAP termination

Works with any RADIUS server that supports PAP or CHAP authentication.

· Supports only the following EAP authentication methods:

? MD5-Challenge EAP authentication.

? The username and password EAP authentication initiated by an iNode 802.1X client.

· The processing is complex on the access device.

EAP relay

Figure 35 shows the basic 802.1X authentication procedure in EAP relay mode, assuming that EAP-MD5 is used.

Figure 35 802.1X authentication procedure in EAP relay mode

The following steps describe the 802.1X authentication procedure:

1. When a user launches the 802.1X client and enters a registered username and password, the 802.1X client sends an EAPOL-Start packet to the access device.

2. The access device responds with an EAP-Request/Identity packet to ask for the client username.

3. In response to the EAP-Request/Identity packet, the client sends the username in an EAP-Response/Identity packet to the access device.

4. The access device relays the EAP-Response/Identity 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. Then, the server sends the challenge in a RADIUS Access-Challenge packet to the access device.

6. The access device transmits the EAP-Request/MD5-Challenge 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 access device.

8. The access device relays the EAP-Response/MD5-Challenge packet in a RADIUS Access-Request packet to the authentication server.

9. The authentication server compares the received encrypted password with the encrypted password it generated at step 5. If the two passwords are identical, the server considers the client valid and sends a RADIUS Access-Accept packet to the access device.

10. Upon receiving the RADIUS Access-Accept packet, the access device performs the following operations:

a. Sends an EAP-Success packet to the client.

b. Sets the controlled port in authorized state.

The client can access the network.

11. After the client comes online, the 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 number of consecutive handshake attempts (two by default), the access device logs off the client. This handshake mechanism enables timely release of the network resources used by 802.1X users who have abnormally gone offline.

13. The client can also send an EAPOL-Logoff packet to ask the access device for a logoff.

14. In response to the EAPOL-Logoff packet, the access device changes the status of the controlled port from authorized to unauthorized. Then, the access device sends an EAP-Failure packet to the client.

EAP termination

Figure 36 shows the basic 802.1X authentication procedure in EAP termination mode, assuming that CHAP authentication is used.

Figure 36 802.1X authentication procedure in EAP termination mode

In EAP termination mode, the access device rather than the authentication server generates an MD5 challenge for password encryption. The access device then sends the MD5 challenge together with the username and encrypted password in a standard RADIUS packet to the RADIUS server.

Configuring 802.1X

802.1X VLAN manipulation

For information about 802.1X VLAN manipulation, see WLAN authentication in WLAN Configuration Guide.

Using 802.1X authentication with other features

ACL assignment

You can specify an ACL for an 802.1X user to control the user's access to network resources. After the user passes 802.1X authentication, the authentication server assigns the ACL to the service template to filter traffic for this user. The authentication server can be the local access device or a RADIUS server. In either case, you must configure the ACL on the access device.

To change the access control criteria for the user, you can use one of the following methods:

· Modify ACL rules on the access device.

· Specify another authorization ACL on the authentication server.

For more information about ACLs, see ACL and QoS Configuration Guide.

User profile assignment

You can specify a user profile for an 802.1X user to control the user's access to network resources. After the user passes 802.1X authentication, the authentication server assigns the user profile to the user for filtering traffic. The authentication server can be the local access device or a RADIUS server. In either case, you must configure the user profile on the access device.

To change the user's access permissions, you can use one of the following methods:

· Modify the user profile configuration on the access device.

· Specify another user profile for the user on the authentication server.

For more information about user profiles, see "Configuring user profiles."

EAD assistant

Endpoint Admission Defense (EAD) is an H3C integrated endpoint access control solution to improve the threat defensive capability of a network. The solution enables the security client, security policy server, access device, and third-party server to operate together. If a terminal device seeks to access an EAD network, it must have an EAD client, which performs 802.1X authentication.

The EAD assistant feature enables the access device to redirect a user who is seeking to access the network to download and install an EAD client. This feature eliminates the administrative task to deploy EAD clients.

EAD assistant is implemented by the following functionality:

· Free IP.

A free IP is a freely accessible network segment, which has a limited set of network resources such as software and DHCP servers. To ensure security strategy compliance, an unauthenticated user can access only this segment to perform operations. For example, the user can download EAD client from a software server or obtain a dynamic IP address from a DHCP server.

· Redirect URL.

If an unauthenticated 802.1X user is using a Web browser to access the network, the EAD assistant feature redirects the user to a specific URL. For example, you can use this feature to redirect the user to the EAD client software download page.

The EAD assistant feature creates an ACL-based EAD rule automatically to open access to the redirect URL for each redirected user.

EAD rules are implemented by using ACL resources. When the EAD rule timer expires or the user passes authentication, the rule is removed. If users fail to download EAD client or fail to pass authentication before the timer expires, they must reconnect to the network to access the free IP.

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

Configuration prerequisites

Before you configure 802.1X, complete the following tasks:

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

802.1X configuration task list

Tasks at a glance
(Required.) Enabling EAP relay or EAP termination
(Optional.) Setting the maximum number of authentication request attempts
(Optional.) Setting the 802.1X authentication timeout timers
(Optional.) Specifying supported domain name delimiters
(Optional.) Configuring the EAD assistant feature

Enabling EAP relay or EAP termination

When configuring EAP relay or EAP termination, consider the following factors:

· Support of the RADIUS server for EAP packets.

· Authentication methods supported by the 802.1X client and the RADIUS server.

You can use both EAP termination and EAP relay in any of the following situations:

· The client is using only MD5-Challenge EAP authentication. If EAP termination is used, you must enable CHAP authentication on the access device.

· The client is an iNode 802.1X client and initiates only the username and password EAP authentication. If EAP termination is used, you can enable either PAP or CHAP authentication on the access device. However, if the password is required to be transmitted in cipher text, you must use CHAP authentication on the access device.

To use EAP-TLS, 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:

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Configure EAP relay or EAP termination.

dot1x authentication-method { chap | eap | pap }

By default, the access device performs EAP termination and uses CHAP to communicate with the RADIUS server.

Specify the eap keyword to enable EAP relay.

Specify the chap or pap keyword to enable CHAP-enabled or PAP-enabled EAP termination.

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 maximum number of authentication request attempts

The access device retransmits an authentication request if it does not receive any responses to the request from the client within a period of time. To set the time, use the dot1x timer tx-period tx-period-value command or the dot1x timer supp-timeout supp-timeout-value command. The access device stops retransmitting the request if it has made the maximum number of request transmission attempts but still receives 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 retries	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 timer—Starts 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 timer—Starts 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.

In most cases, the default settings are sufficient. You can edit the timers, depending on the network conditions.

· In a low-speed network, increase the client timeout timer.

· In a network with authentication servers of different performance, adjust the server timeout timer.

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.

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 who use other domain name delimiters. The configurable delimiters include the at sign (@), backslash (\), dot (.), and forward slash (/). Usernames that include domain names can use the format of username@domain-name, domain-name\username, username.domain-name, or username/domain-name.

If an 802.1X username string contains multiple configured delimiters, the rightmost delimiter is the domain name delimiter. For example, if you configure the backslash (\), dot (.), and forward slash (/) as delimiters, the domain name delimiter for the username string 121.123/22\@abc is the backslash (\). The username is @abc and the domain name is 121.123/22.

If a username string contains none of the delimiters, the access device authenticates the user in the mandatory or default ISP domain.

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 send usernames with domain names to the RADIUS server, make sure the domain delimiter can be recognized by the RADIUS server. For username format configuration, see the user-name-format command in Security Command Reference.

Configuring the EAD assistant feature

When you configure the EAD assistant feature, follow these restrictions and guidelines:

· For EAD assistant to take effect on a service template, you must first disable MAC authentication on the service template.

· When MAC authentication is enabled on a service template, the free IP does not take effect on the service template.

· To allow a user to obtain a dynamic IP address before it passes 802.1X authentication, make sure the DHCP server is on the free IP segment.

· The server that provides the redirect URL must be on the free IP accessible to unauthenticated users.

· To avoid using up ACL resources when a large number of EAD users exist, you can shorten the EAD rule timer.

To configure the EAD assistant feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable EAD assistant.	dot1x ead-assistant enable	By default, this feature is disabled.
3. Configure a free IP.	dot1x ead-assistant free-ip ip-address { mask-length \| mask-address }	By default, no free IP is configured.
4. (Optional.) Configure the redirect URL.	dot1x ead-assistant url url-string	By default, no redirect URL is configured. Configure the redirect URL if users will use Web browsers to access the network.
5. (Optional.) Set the EAD rule timer.	dot1x timer ead-timeout ead-timeout-value	The default setting is 30 minutes.

Displaying and maintaining 802.1X

Execute display commands in any view and reset commands in user view.

Task	Command
Display 802.1X session information, statistics, or configuration information.	display dot1x [ sessions \| statistics ] [ ap ap-name [ radio radio-id ] ]
Display online 802.1X user information.	display dot1x connection [ ap ap-name [ radio radio-id ] \| slot slot-number \| user-mac mac-address \| user-name name-string ]
Clear 802.1X statistics.	reset dot1x statistics [ ap ap-name [ radio radio-id ] ]

Troubleshooting 802.1X

EAD assistant for Web browser users

Symptom

Unauthenticated users are not redirected to the specified redirect URL after they enter external website addresses in their Web browsers.

Analysis

Redirection will not happen for one of the following reasons:

· The address is in the string format. The operating system of the host regards the string as a website name and tries to resolve the string. If the resolution fails, the operating system sends an ARP request, but the target address is not in the dotted decimal notation. The redirection feature does redirect this kind of ARP request.

· The address is within a free IP segment. No redirection will take place, even if no host is present with the address.

· The redirect URL is not in a free IP segment.

· No server is using the redirect URL, or the server with the URL does not provide Web services.

Solution

To resolve the problem:

1. Enter a dotted decimal IP address that is not in any free IP segments.

2. Verify that the access device and the server are configured correctly.

3. If the problem persists, contact H3C Support.

Configuring 802.1X client

As shown in Figure 37, the 802.1X client feature allows the access device to act as the supplicant in the 802.1X architecture. For information about the 802.1X architecture, see "802.1X overview."

Figure 37 802.1X client network diagram

802.1X client configuration task list

Tasks at a glance
(Required.) Enabling the 802.1X client feature
(Required.) Configuring the 802.1X client username and password
(Required.) Specifying the 802.1X client EAP authentication method
(Optional.) Configuring the 802.1X client anonymous identifier

Enabling the 802.1X client feature

Before enabling the 802.1X client feature, make sure you have configured 802.1X authentication on the authenticator. For information about 802.1X configuration, see "Configuring 802.1X."

If an 802.1X client-enabled AP has online clients, disabling the 802.1X client feature will log off these online clients.

To enable the 802.1X client feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a manual AP and enter AP view.	wlan ap ap-name [ model model-name ]	By default, no manual APs exist. You must specify the model name when you create an AP.
3. Enable AP preprovisioning and enter AP provision view.	provision	By default, AP preprovisioning is disabled.
4. Enable the 802.1X client feature.	dot1x supplicant enable	By default, the 802.1X client feature is disabled.

Configuring the 802.1X client username and password

An 802.1X client-enabled device uses the configured username and password for 802.1X authentication.

Make sure the username and password configured on the device is consistent with the username and password configured on the authentication server. If any inconsistency occurs, the device cannot pass 802.1X authentication to access the network.

To configure the 802.1X client username and password:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a manual AP and enter AP view.	wlan ap ap-name [ model model-name ]	N/A
3. Enable AP preprovisioning and enter AP provision view.	provision	N/A
4. Configure the 802.1X client username.	dot1x supplicant username username	By default, no 802.1X client username exists.
5. Set the 802.1X client password.	dot1x supplicant password { cipher \| simple } password	By default, no 802.1X client password exists.

Specifying the 802.1X client EAP authentication method

An 802.1X client-enabled device supports the following EAP authentication methods:

· MD5-Challenge.

· PEAP-MSCHAPv2.

· PEAP-GTC.

· TTLS-MSCHAPv2.

· TTLS-GTC.

An 802.1X authenticator supports the EAP relay and EAP termination modes. Support of the EAP authentication methods for the two modes varies.

· The MD5-Challenge EAP authentication supports both modes.

· Other EAP authentication methods support only the EAP relay mode.

For information about EAP relay and EAP termination, see "Configuring 802.1X."

To specify the 802.1X client EAP authentication method:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a manual AP and enter AP view.	wlan ap ap-name [ model model-name ]	N/A
3. Enable AP preprovisioning and enter AP provision view.	provision	N/A
4. Specify the 802.1X client EAP authentication method.	dot1x supplicant eap-method { md5 \| peap-gtc \| peap-mschapv2 \| ttls-gtc \| ttls-mschapv2 }	By default, the 802.1X client-enabled device uses the MD5-Challenge EAP authentication. Make sure the specified 802.1X client EAP authentication method is supported by the RADIUS server.

Configuring the 802.1X client anonymous identifier

At the first authentication phase, packets sent to the authenticator are not encrypted. The use of an 802.1X client anonymous identifier prevents the 802.1X client username from being disclosed at the first phase. The 802.1X client-enabled device sends the anonymous identifier to the authenticator instead of the 802.1X client username. The 802.1X client username will be sent to the authenticator in encrypted packets at the second phase.

If no 802.1X client anonymous identifier is configured, the device sends the 802.1X client username at the first authentication phase.

The configured 802.1X client anonymous identifier takes effect only if one of the following EAP authentication methods is used:

· PEAP-MSCHAPv2.

· PEAP-GTC.

· TTLS-MSCHAPv2.

· TTLS-GTC.

If the MD5-Challenge EAP authentication is used, the configured 802.1X client anonymous identifier does not take effect. The device still uses the 802.1X client username at the first authentication phase.

Do not configure the 802.1X client anonymous identifier if the vendor-specific authentication server cannot identify anonymous identifiers.

To configure the 802.1X client anonymous identifier:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a manual AP and enter AP view.	wlan ap ap-name [ model model-name ]	N/A
3. Enable AP preprovisioning and enter AP provision view.	provision	N/A
4. Configure the 802.1X client anonymous identifier.	dot1x supplicant anonymous identify identifier	By default, no 802.1X client anonymous identifier exists.

802.1X client configuration example

Network requirements

As shown in Figure 38, the switch acts as the authenticator to perform 802.1X client authentication for the AP that connects to the port GigabitEthernet 1/0/1.

Configure the switch to meet the following requirements:

· Use RADIUS servers to perform 802.1X authentication and authorization for the AP.

· Enable EAP relay for the switch to communicate with the RADIUS servers.

· Assign the AP to the ISP domain bbb.

· Set the shared key to name for secure communication between the switch and the RADIUS servers.

· Implement 802.1X port-based access control for the AP.

Perform the following tasks on the AC:

· Enable the 802.1X client feature for the AP.

· Set the following 802.1X client parameters for the AP:

? Configure the authentication username as aaa.

? Set the password to 123456 in plain text.

? Specify PEAP-MSCHAPv2 as the EAP authentication method.

· Save the 802.1X client settings to the configuration file on the AP.

Figure 38 Network diagram

Configuration procedure

1. Configure the RADIUS servers:

# Add a user account with the username aaa and password 123456. (Details not shown.)

# Configure the servers to provide authentication and authorization services. (Details not shown.)

2. Configure the AC:

a. Assign an IP address to each interface, as shown in Figure 38. (Details not shown.)

b. Configure the 802.1X client feature:

# Create a manual AP named ap1, and specify the AP model and serial ID.

<AC> system-view

[AC] wlan ap ap1 model WA536-WW

[AC-wlan-ap-ap1] serial-id 219801A1NQB117012935

# Enable AP preprovisioning and enter AP provision view.

[AC-wlan-ap-ap1] provision

# Specify PEAP-MSCHAPv2 as the 802.1X client EAP authentication method.

[AC-wlan-ap-ap1-prvs] dot1x supplicant eap-method peap-mschapv2

# Configure the 802.1X client username as aaa, and set the password to 123456 in plain text.

[AC-wlan-ap-ap1-prvs] dot1x supplicant username aaa

[AC-wlan-ap-ap1-prvs] dot1x supplicant password simple 123456

# Configure the 802.1X client anonymous identifier as bbb.

[AC-wlan-ap-ap1-prvs] dot1x supplicant anonymous identify bbb

# Enable the 802.1X client feature.

[AC-wlan-ap-ap1-prvs] dot1x supplicant enable

# Save the 802.1X client configuration in AP provision view to the configuration file wlan_ap_prvs.xml on the AP ap1.

[AC-wlan-ap-ap1-prvs] save wlan ap provision name ap1

[AC-wlan-ap-ap1-prvs] quit

[AC-wlan-ap-ap1] quit

3. Configure the switch:

a. Assign an IP address to each interface, as shown in Figure 38. (Details not shown.)

b. Configure a RADIUS scheme:

# Create a RADIUS scheme named radius1 and enter RADIUS scheme view.

<Switch> system-view

[Switch] radius scheme radius1

# Specify the IP address of the primary authentication RADIUS server.

[Switch-radius-radius1] primary authentication 10.1.1.1

# Specify the IP address of the secondary authentication RADIUS server.

[Switch-radius-radius1] secondary authentication 10.1.1.2

# Specify the shared key between the switch and the authentication RADIUS servers.

[Switch-radius-radius1] key authentication simple name

# Exclude the ISP domain names from the usernames sent to the RADIUS servers.

[Device-radius-radius1] user-name-format without-domain

[Device-radius-radius1] quit

NOTE:

The authenticator must use the same username format as the RADIUS server. If the RADIUS server includes the ISP domain name in the username, so must the authenticator.

c. Configure the ISP domain:

# Create an ISP domain named bbb and enter ISP domain view.

[Switch] domain bbb

# Perform authentication and authorization for 802.1X clients in the ISP domain bbb based on the RADIUS scheme radius1.

[Switch-isp-bbb] authentication lan-access radius-scheme radius1

[Switch-isp-bbb] authorization lan-access radius-scheme radius1

[Switch-isp-bbb] accounting lan-access none

[Switch-isp-bbb] quit

d. Configure 802.1X:

# Enable EAP relay.

[Switch] dot1x authentication-method eap

# Enable port-based access control on the port GigabitEthernet 1/0/1.

[Switch] interface gigabitethernet 1/0/1

[Switch-GigabitEthernet1/0/1] dot1x port-method portbased

# Specify the ISP domain bbb as the 802.1X mandatory domain.

[Switch-GigabitEthernet1/0/1] dot1x mandatory-domain bbb

# Enable 802.1X on GigabitEthernet 1/0/1.

[Switch-GigabitEthernet1/0/1] dot1x

[Switch-GigabitEthernet1/0/1] quit

# Enable 802.1X globally.

[Switch] dot1x

Verifying the configuration

# Display online 802.1X client information.

[Switch] display dot1x connection

Total connections: 1

User MAC address: 70f9-6dd7-d1e0

Access interface: GigabitEthernet1/0/1

Username: aaa

Authentication domain: bbb

Authentication method: EAP

Initial VLAN: 1

Authorization untagged VLAN: N/A

Authorization tagged VLAN list: N/A

Authorization ACL ID: N/A

Authorization user profile: N/A

Termination action: N/A

Session timeout period: N/A

Online from: 2015/06/16 19:10:32

Online duration: 0h 1m 1s

Configuring MAC authentication

Overview

MAC authentication controls network access by authenticating source MAC addresses on a service template. The feature does not require client software, and users do not have 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 service template. 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 methods

You can perform MAC authentication on the access device (local authentication) or through a RADIUS server.

Local authentication:

· MAC-based accounts—The access device uses the source MAC address of the packet as the username and password to search the local account database for a match.

· A shared account—The access device uses the shared account username and password to search the local account database for a match.

RADIUS authentication:

· MAC-based accounts—The access device sends the source MAC address of the packet as the username and password to the RADIUS server for authentication.

· A shared account—The access device sends the shared account username and password to the RADIUS server for authentication.

For more information about configuring local authentication and RADIUS authentication, see "Configuring AAA."

VLAN assignment

For information about MAC authentication VLAN assignment, see WLAN authentication in WLAN Configuration Guide.

Periodic MAC reauthentication

Periodic MAC reauthentication tracks the connection status of online users and updates the authorization attributes assigned by the RADIUS server. The attributes include the ACL and VLAN.

The device reauthenticates an online MAC authentication user periodically only after it receives the termination action Radius-request from the authentication server for this user. The Session-Timeout attribute (session timeout period) assigned by the server is the reauthentication interval. To display the server-assigned Session-Timeout and Termination-Action attributes, use the display mac-authentication connection command. Support for the server configuration and assignment of Session-Timeout and Termination-Action attributes depends on the server model.

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

Configuration prerequisites

Before you configure MAC authentication, configure an ISP domain and specify an AAA method. For more information, see "Configuring AAA."

· For local authentication, you must also create local user accounts (including usernames and passwords) and specify the lan-access service for local users.

· For RADIUS authentication, make sure 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 are the same as the MAC address of each MAC authentication user.

Configuration task list

Tasks at a glance
(Optional.) Specifying a MAC authentication domain
(Optional.) Configuring the user account format
(Optional.) Configuring MAC authentication server timeout timer

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 use one of the following methods to specify authentication domains for MAC authentication users:

· Specify a global authentication domain in system view. This domain setting applies to all service templates enabled with MAC authentication.

· Specify an authentication domain for an individual service template in service template view.

MAC authentication chooses an authentication domain for users on a service template in this order: the service template-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

Command

Remarks

1. Enter system view.

system-view

N/A

2. Specify an authentication domain for MAC authentication users.

· In system view:
mac-authentication domain domain-name

· In service template view:

a. wlan service-template service-template-name

b. mac-authentication domain domain-name

By default, the system default authentication domain is used for MAC authentication users.

Configuring the user account format

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Configure the MAC authentication user account format.

· Use one MAC-based user account for each user:
mac-authentication user-name-format mac-address [ { with-hyphen [ six-section | three-section ] | without-hyphen } [ lowercase | uppercase ] ]

· Use one shared user account for all users:
mac-authentication user-name-format fixed [ account name ] [ password { cipher | simple } string ]

By default, the device uses the MAC address of a user as the username and password for MAC authentication. The MAC address is in the hexadecimal notation without hyphens, and letters are in lower case.

Configuring MAC authentication server timeout timer

MAC authentication uses the server timeout timer to set the interval that the device waits for a response from a RADIUS server before the device regards the RADIUS server unavailable. If the timer expires during MAC authentication, the user cannot access the network.

To configure the MAC authentication server timeout timer:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Configure the MAC authentication server timeout timer.	mac-authentication timer server-timeout server-timeout-value	By default, the server timeout timer is 100 seconds.

Displaying and maintaining MAC authentication

Execute display commands in any view and reset commands in user view.

Task	Command
Display MAC authentication information.	display mac-authentication [ ap ap-name [ radio radio-id ] ]
Display MAC authentication connections.	display mac-authentication connection [ ap ap-name [ radio radio-id ] \| slot slot-number \| user-mac mac-address \| user-name user-name ]
Clear MAC authentication statistics.	reset mac-authentication statistics [ ap ap-name [ radio radio-id ] ]

Configuring portal authentication

Overview

Portal authentication controls user access to the Internet. Portal authenticates a user by the username and password the user enters on a portal authentication page. Therefore, portal authentication is also known as Web authentication. When portal authentication is deployed on a network, an access device redirects unauthenticated users to the website provided by a portal Web server. The users can access the resources on the website without authentication. If the users want to access the Internet, they must pass authentication on the website.

Portal authentication is classified into the following types:

· Active authentication—Users visit the authentication website provided by the portal Web server and enter their username and password for authentication.

· Forced authentication—Users are redirected to the portal authentication website for authentication when they visit other websites.

Portal authentication flexibly imposes access control on the access layer and vital data entries. It has the following advantages:

· Allows users to perform authentication through Web pages without installing client software.

· Provides ISPs with diversified management choices and extended functions. For example, the ISPs can place advertisements, provide community services, and publish information on the authentication page.

The device supports Portal 1.0, Portal 2.0, and Portal 3.0.

Extended portal functions

By forcing patching and anti-virus policies, extended portal functions help hosts to defend against viruses. Portal supports the following extended functions:

· Security check—Detects after authentication whether or not a user host installs anti-virus software, virus definition file, unauthorized software, and operating system patches.

· Resource access restriction—Allows an authenticated user to access certain network resources such as the virus server and the patch server. Users can access more Internet resources after passing security check.

Security check must cooperate with the H3C IMC security policy server and the iNode client.

Portal system components

A typical portal system consists of these basic components: authentication client, access device, portal authentication server, portal Web server, AAA server, and security policy server.

Figure 39 Portal system components

Authentication client

An authentication client is a Web browser that runs HTTP/HTTPS or a user host that runs a portal client application. Security check for the user host is implemented through the interaction between the portal client and the security policy server.

Access device

An access device refers to a broadband access device such as an access controller. An access device has the following functions:

· Redirects all HTTP requests of unauthenticated users to the portal Web server.

· Interacts with the portal authentication server and the AAA server to complete authentication, authorization, and accounting.

· Allows users that pass portal authentication to access authorized Internet resources.

Portal authentication server

The portal authentication server receives authentication requests from authentication clients and interacts with the access device to authenticate users.

Portal Web server

The portal Web server pushes the Web authentication page to authentication clients and forwards user authentication information (username and password) to the portal authentication server. The access device also redirects HTTP requests from unauthenticated users to the portal Web server.

The portal Web server can be integrated with the portal authentication server or an independent server.

AAA server

The AAA server interacts with the access device to implement authentication, authorization, accounting for portal users. In a portal system, a RADIUS server can perform authentication, authorization, accounting for portal users, and an LDAP server can perform authentication for portal users.

Security policy server

The security policy server interacts with the portal client and the access device for security check and authorization for users.

Portal system using the local portal Web server

The access device supports the local portal Web server feature to provide the local portal service for portal users. Using this feature, the access device also acts as the portal Web server and the portal authentication server. In this case, the portal system consists of only three components: authentication client, access device, and authentication/accounting server, as shown in Figure 40.

Figure 40 Portal system using the local portal Web server

The authentication client cannot be an H3C iNode client. The local portal service supports only Web clients.

No security policy server is needed, because the local portal service does not support extended portal functions.

The local portal Web server feature implements only some simple portal server functions. It only allows users to log in and log out through the Web interface. It cannot take the place of an independent portal Web and authentication servers.

Client and local portal Web server interaction protocols

HTTP and HTTPS can be used for interaction between an authentication client and a local portal Web server. If HTTP is used, there are potential security problems because HTTP packets are transferred in plain text. If HTTPS is used, secure data transmission is ensured because HTTP packets are secured by SSL.

Portal page customization

The local portal Web server provides a set of default authentication pages. You can customize multiple sets of authentication pages, compress each set of the pages to a .zip file, and upload the compressed files to the storage medium of the device.

For more information about authentication page customization, see "Customizing authentication pages."

Interaction between portal system components

The components of a portal system interact as follows:

1. An unauthenticated user initiates authentication by accessing an Internet website through a Web browser. When receiving the HTTP or HTTPS request, the access device redirects it to the Web authentication page provided by the portal Web server. The user can also visit the authentication website to log in. The user must log in through the H3C iNode client for extended portal functions.

2. The user enters the authentication information on the authentication page/dialog box and submits the information. The portal Web server forwards the information to the portal authentication server. Then the portal authentication server processes the information and forwards it to the access device.

3. The access device interacts with the AAA server to implement authentication, authorization, accounting for the user.

4. If security policies are not imposed on the user, the access device allows the authenticated user to access the Internet. If security policies are imposed on the user, the portal client, the access device, and the security policy server interact to check the user host. If the user passes the security check, the security policy server authorizes the user to access resources based on the check result. Portal authentication through Web does not support security check for users. To implement security check, the client must be the H3C iNode client.

NOTE:

Portal authentication supports NAT traversal whether it is initiated by a Web client or an H3C iNode client. NAT traversal must be configured when the portal client is on a private network and the portal server is on a public network.

Portal authentication mode

Portal authentication supports only direct authentication. In direct authentication, no Layer 3 forwarding devices exist between the authentication client and the access device. A user manually configures a public IP address or obtains a public IP address through DHCP. Before authentication, the user can access only the portal Web server and predefined authentication-free websites. After passing authentication, the user can access other network resources.

Portal support for EAP

Compared with username and password based authentication, digital certificate-based authentication ensures 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 41 Portal support for EAP working flow diagram

As shown in Figure 41, the authentication client and the portal authentication server exchange EAP authentication packets. The portal authentication 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.

The access device does not process but only transports EAP-Message attributes between the portal authentication server and the RADIUS server. Therefore, the access device requires no additional configuration to support EAP authentication.

NOTE:

· To use portal authentication that supports EAP, the portal authentication server and client must be the H3C IMC portal server and the H3C iNode portal client.

· Local portal authentication does not support EAP authentication.

Portal authentication process

Figure 42 Portal authentication process

The portal authentication process is as follows:

1. A portal user access the Internet through HTTP, and the HTTP packet arrives at the access device.

? If the packet matches a portal free rule, the access device allows the packet to pass.

? If the packet does not match any portal-free rule, the access device redirects the packet to the portal Web server. The portal Web server pushes the Web authentication page to the user for him to enter his username and password.

2. The portal Web server submits the user authentication information to the portal authentication server.

3. The portal authentication server and the access device exchange CHAP messages. This step is skipped for PAP authentication. The portal authentication server decides the method (CHAP or PAP) to use.

4. The portal authentication server adds the username and password into an authentication request packet and sends it to the access device. Meanwhile, the portal authentication server starts a timer to wait for an authentication reply packet.

5. The access device and the RADIUS server exchange RADIUS packets.

6. The access device sends an authentication reply packet to the portal authentication server to notify authentication success or failure.

7. The portal authentication server sends an authentication success or failure packet to the client.

8. If the authentication is successful, the portal authentication server sends an authentication reply acknowledgment packet to the access device.

If the client is an iNode client, the authentication process includes step 9 and step 10 for extended portal functions. Otherwise the authentication process is complete.

9. The client and the security policy server exchange security check information. The security policy server detects whether or not the user host installs anti-virus software, virus definition files, unauthorized software, and operating system patches.

10. The security policy server authorizes the user to access certain network resources based on the check result. The access device saves the authorization information and uses it to control access of the user.

Portal filtering rules

The access device uses portal filtering rules to control user traffic forwarding on a portal-enabled interface or service template.

Based on the configuration and authentication status of portal users, the device generates the following categories of portal packet filtering rules:

· Category 1—Permits user packets that are destined for the portal Web server and packets that match the portal-free rules to pass through.

· Category 2—For an authenticated user with no ACL authorized, the rule allows the user to access any destination network resources. For an authenticated user with an ACL authorized, the rule allows users to access resources permitted by the ACL. The device adds the rule when a user comes online and deletes the rule when the user goes offline.

· Category 3—Redirects all HTTP requests from unauthenticated users to the portal Web server.

· Category 4—Forbids any user packets to pass through.

After receiving a user packet, the device compares the packet against the filtering rules from category 1 to category 4. Once the packet matches a rule, the matching process completes.

BYOD support

The BYOD feature must work with the IMC server. During portal authentication, the device encapsulates obtained DHCP Option 55 information into portal and RADIUS packets and then uploads them to the UAM component of the IMC server.

Based on DHCP Option 55 information, UAM identifies the endpoint type, OS, and vendor information. UAM pushes different authentication pages and deploys different authorization information to different endpoints.

MAC-based quick portal authentication

MAC-based quick portal authentication is applicable to scenarios where users access the network frequently. It allows users to pass authentication without entering username and password. MAC-based quick portal authentication is also called MAC-trigger authentication or transparent portal authentication.

A MAC binding server is required for MAC-trigger authentication. The MAC binding server records the MAC-to-account bindings of portal users for authentication. The account contains the portal authentication information of the user, including username and password.

MAC-based quick portal authentication modes include local authentication and remote authentication.

The authentication is implemented as follows:

1. When a user accesses the network, the access device generates a MAC-trigger entry that records the user's MAC address and access interface. The user can access the network without performing portal authentication if the user's network traffic is below the free-traffic threshold.

2. When the user's network traffic reaches the threshold, the access device sends a MAC binding query to the MAC binding server.

3. The MAC binding server checks whether a matching MAC-account binding entry exists. A MAC-account binding entry records the MAC address and the portal account information of a portal user.

4. According to the check result, the user is authenticated as follows:

? If a matching MAC-account binding entry exists, the MAC binding server sends the user authentication information to the access device to initiate portal authentication. The user is authenticated without entering the username and password.

- If the user fails portal authentication, an authentication failure message is returned to the user. The MAC-trigger entry of the user on the access device is deleted when the entry ages out.

- If the user passes portal authentication, the access device deletes the MAC-trigger entry of the user.

? If no matching MAC-account binding entry exists, the MAC binding server notifies the access device to perform normal portal authentication for the user.

- If the user fails portal authentication, an authentication failure message is returned to the user. The whole process is finished.

- If the user passes portal authentication, the access device deletes the user's MAC-trigger entry and sends the user's MAC address and authentication information to the MAC binding server. The MAC binding server creates a MAC-account binding entry for the user.

In wireless networks where APs are configured to forward client data traffic, APs report traffic statistics to the AC at a regular interval. The AC can determine whether a user's traffic exceed the free-traffic threshold only after receiving the traffic statistics report from the associated AP. For information about setting the report interval, see "Setting the interval at which an AP reports traffic statistics to the AC."

For information about MAC binding server configuration, see the user manual of the server.

Portal authentication configuration in wireless networks

There are two forwarding modes for client data in a fit AP+AC network:

· Centralized forwarding—The AP sends data frames from clients to the AC over the CAPWAP tunnel, and the AC forwards all data frames.

· Local forwarding—The AP directly forwards data frames from clients, instead of sending them to the AC for packet forwarding.

On the AC, you can configure portal authentication on a VLAN interface or a service template according to the client data forwarding mode.

· Portal authentication on a VLAN interface is applicable only in centralized forwarding mode.

The AC authenticates only the user packets that are received from the VLAN interface. In local forwarding mode, the AC cannot receive client data and therefore it cannot perform portal authentication for clients.

· Portal authentication on a service template is applicable in both centralized and local forwarding modes.

The AC deploys portal packet filtering rules to the BSS on this AC in centralized forwarding mode and to the BSS on an AP in local forwarding mode. The AC can authenticate users from all APs that are bound to the service template.

For more information about client traffic forwarding, see WLAN Configuration Guide.

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

Portal configuration task list

Tasks at a glance
(Optional.) Configuring a portal authentication server
(Required.) Configuring a portal Web server
(Required.) Enabling portal authentication
(Required.) Specifying a portal Web server
(Optional.) Controlling portal user access · Configuring a portal-free rule · Configuring an authentication destination subnet · Setting the maximum number of portal users · Specifying a portal authentication domain · Specifying a preauthentication domain · Specifying a preauthentication IP address pool for portal users · Enabling strict-checking on portal authorization information · Allowing only portal clients with DHCP-assigned IP addresses to pass portal authentication · Enabling outgoing packets filtering
(Optional.) Configuring portal detection features · Configuring online detection of portal users · Configuring portal authentication server detection · Configuring portal Web server detection · Configuring portal user synchronization
(Optional.) Configuring the portal fail-permit feature
(Optional.) Configuring BAS-IP for portal packets sent to the portal authentication server
(Optional.) Specifying the device ID
(Optional.) Enabling portal roaming
(Optional.) Specifying a format for the NAS-Port-Id attribute
(Optional.) Logging out online portal users
(Optional.) Configuring Web redirect
(Optional.) Applying a NAS-ID profile to an interface
(Optional.) Configuring the local portal Web server feature
(Optional.) Enabling validity check on wireless clients
(Optional.) Automatically logging out wireless portal users
(Optional.) Enabling ARP or ND entry conversion for portal clients
(Optional.) Configuring HTTPS redirect
(Optional.) Configuring MAC-based quick portal authentication
(Required.) Configuring NAS-Port-Type
(Optional.) Configuring portal safe-redirect
(Optional.) Setting the interval at which an AP reports traffic statistics to the AC
(Optional.) Excluding an attribute from portal protocol packets
(Optional.) Enabling portal logging
(Optional.) Configuring portal support for third-party authentication: · Editing buttons and pages for third-party authentication · Configuring a third-party authentication server · Specifying an authentication domain for third-party authentication · Configuring portal temporary pass
(Optional.) Configuring the portal authentication monitoring feature
(Optional.) Setting the user synchronization interval for portal authentication using OAuth
(Optional.) Logging out wireless portal users that switch SSIDs

Configuration prerequisites

The portal feature provides a solution for user identity authentication and security check. To complete user identity authentication, portal must cooperate with RADIUS.

The prerequisites for portal authentication configuration are as follows:

· The portal authentication server, portal Web server, and RADIUS server have been installed and configured correctly.

· The portal client, access device, and servers can reach each other.

· To use the remote RADIUS server, configure usernames and passwords on the RADIUS server, and configure the RADIUS client on the access device. For information about RADIUS client configuration, see "Configuring AAA."

· To implement extended portal functions, install and configure CAMS EAD or IMC EAD. Make sure the ACLs configured on the access device correspond to the isolation ACL and the security ACL 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 CAMS EAD Security Policy Component User Manual or IMC EAD Security Policy Help.

Configuring a portal authentication server

Configure this feature when user authentication uses an external portal authentication server.

Perform this task to configure the following portal authentication server parameters:

· IP address of the portal authentication server.

· Shared encryption key used between the device and the portal authentication server.

· Destination UDP port number used by the device to send unsolicited portal packets to the portal authentication server.

· Portal authentication server type, which must be the same as the server type the device actually uses.

The device supports multiple portal authentication servers.

Do not delete a portal authentication server in use. Otherwise, users authenticated by that server cannot log out normally.

To configure a portal authentication server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a portal authentication server, and enter its view.	portal server server-name	By default, no portal authentication servers exist.
3. Specify the IP address of the portal authentication server.	· To specify an IPv4 portal server: ip ipv4-address [ key { cipher \| simple } string ] · To specify an IPv6 portal server: ipv6 ipv6-address [ key { cipher \| simple } string ]	Specify an IPv4 portal authentication server, an IPv6 authentication portal server, or both. By default, no portal authentication server is specified.
4. (Optional.) Set the destination UDP port number used by the device to send unsolicited portal packets to the portal authentication server.	port port-number	By default, the UDP port number is 50100. This port number must be the same as the listening port number specified on the portal authentication server.
5. (Optional.) Specify the portal authentication server type.	server-type { cmcc \| imc }	By default, the portal authentication server type is IMC.
6. Return to system view.	quit	N/A
7. (Optional.) Set the maximum number of times and the interval for retransmitting a logout notification packet.	logout-notify retry retries interval interval	By default, the device does not retransmit a logout notification packet.
8. (Optional.) Set the interval at which the device registers with the portal authentication server.	server-register [ interval interval-value ]	By default, the device does not register with a portal authentication server.
9. (Optional.) Specify the AC's interface for portal clients to access during third-party authentication.	portal client-gateway interface interface-type interface-number	By default, no AC's interface is specified for portal clients to access during third-party authentication.

Configuring a portal Web server

The device supports multiple portal Web servers.

Perform this task to configure the following portal Web server parameters:

· URL of the portal Web server.

· Parameters carried in the URL when the device redirects the URL to users.

· Portal Web server type, which must be the same as the server type the device actually uses.

· Captive-bypass feature.

With the captive-bypass feature enabled, the device does not automatically push the portal authentication page to iOS devices and some Android devices when they are connected to the network. The device pushes the portal authentication page only when the user accesses the Internet by using a browser.

With the optimized captive-bypass feature enabled, the device automatically pushes the portal authentication page to iOS mobile devices when they are connected to the network. Users can perform authentication on the page or press the home button to return to the desktop without performing authentication, and the Wi-Fi connection is not terminated.

Optimized captive-bypass might fail in some conditions. For example, when the network condition is poor, the device cannot receive server detection packets from iOS mobile devices within the captive-bypass detection timeout time. Therefore, the Wi-Fi connection might be terminated on the iOS mobile devices. To avoid such failure, you can set a longer captive-bypass detection timeout time when the network condition is poor.

· URL redirection match rule.

A URL redirection match rule matches HTTP requests by user-requested URL or User-Agent information, and redirects the matching HTTP requests to the specified redirection URL.

For a user to successfully access a redirection URL, configure a portal-free rule to allow HTTP requests destined for the redirection URL to pass. For information about configuring portal-free rules, see the portal free-rule command.

The url command redirects all HTTP or HTTPS requests from unauthenticated users to the portal Web server for authentication. The if-match command allows for flexible URL redirection by redirecting specific HTTP or HTTPS requests to specific redirection URLs. If both commands are configured for a portal Web server, the if-match command takes priority to perform URL redirection.

The device does not detect the reachability of the redirection URL configured by the if-match command. If the if-match command rather than the url command is configured to redirect HTTP requests to portal Web servers, the device does not trigger the following features:

? The fail-permit feature for the portal Web servers.

? The switch between primary and backup portal Web servers.

To configure a portal Web server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a portal Web server and enter its view.	portal web-server server-name	By default, no portal Web servers exist.
3. Specify the URL of the portal Web server.	url url-string	By default, no URL is specified.
4. Configure the parameters to be carried in the URL when the device redirects it to users.	url-parameter param-name { nas-id \| nas-port-id \| original-url \| source-address \| ssid \| { ap-mac \| source-mac } [ encryption { aes \| des } key { cipher \| simple } string ] \| value expression \| vlan }	By default, no redirection URL parameters are configured.
5. (Optional.) Specify the portal Web server type.	server-type { cmcc \| imc \| oauth }	By default, the portal Web server type is IMC. The oauth keyword is restricted to Hong Kong and Macao.
6. (Optional.) Enable the captive-bypass feature.	captive-bypass [ android \| ios [ optimize ] ] enable	By default, the captive-bypass feature is disabled. The device automatically pushes the portal authentication page to the iOS devices and some Android devices when they are connected to the network.
7. (Optional.) Configure a match rule for URL redirection.	if-match { original-url url-string redirect-url url-string [ url-param-encryption { aes \| des } key { cipher \| simple } string ] \| user-agent string redirect-url url-string }	By default, no URL redirection match rules exist.
8. Return to system view.	quit	N/A
9. (Optional.) Set the captive-bypass detection timeout time.	portal captive-bypass optimize delay seconds	By default, the captive-bypass detection timeout time is 6 seconds.

Enabling portal authentication

CAUTION:

Do not enable portal authentication on both a VLAN interface and a service template.

You must first enable portal authentication on a VLAN interface or service template before it can perform portal authentication for connected clients.

With portal authentication enabled, the device searches for a portal authentication server for a received portal packet according to the source IP address of the packet.

· If the packet matches a locally configured portal authentication server, the device regards the packet valid and sends an authentication response packet to the portal authentication server. After a user logs in to the device, the user interacts with the portal authentication server as needed.

· If the packet does not match a portal authentication server, the device drops the packet.

Configuration restrictions and guidelines

When you enable portal authentication, follow these restrictions and guidelines:

· You can enable both IPv4 portal authentication and IPv6 portal authentication on a VLAN interface.

· When local forwarding is used in wireless networks, enable validity check on wireless clients.

Configuration procedure

To enable portal authentication on a VLAN interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Enable portal authentication on the VLAN interface.	· To enable IPv4 portal authentication: portal enable method direct · To enable IPv6 portal authentication: portal ipv6 enable method direct	Enable IPv4 portal authentication, IPv6 portal authentication, or both on a VLAN interface. By default, portal authentication is disabled on a VLAN interface.

To enable portal authentication on a service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Enable portal authentication on the service template.	· To enable IPv4 portal authentication: portal enable method direct · To enable IPv6 portal authentication: portal ipv6 enable method direct	Enable IPv4 portal authentication, IPv6 portal authentication, or both on a service template. By default, portal authentication is disabled on a service template.

Specifying a portal Web server

With a portal Web server specified on a VLAN interface, the device redirects the HTTP or HTTPS requests of portal users on the VLAN interface to the portal Web server.

With a portal Web server specified on a service template, the device redirects the HTTP or HTTPS requests of portal users on the WLAN-BSS interfaces bound to the service template to the portal Web server.

IPv4 and IPv6 portal authentication can both be enabled on a VLAN interface or on a service template. You can specify both a primary portal Web server and a backup portal Web server after enabling each type (IPv4 or IPv6) of portal authentication.

The device first uses the primary portal Web server for portal authentication. When the primary portal Web server is unreachable but the backup portal Web server is reachable, the device uses the backup portal Web server. When the primary portal Web server becomes reachable, the device switches back to the primary portal Web server for portal authentication.

To automatically switch between the primary portal Web server and the backup portal Web server, configure portal Web server detection on both servers.

To specify a portal Web server on a VLAN interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Specify a portal Web server on the VLAN interface.	· To specify an IPv4 portal Web server: portal apply web-server server-name [ secondary ] · To specify an IPv6 portal Web server: portal ipv6 apply web-server server-name [ secondary ]	Specify an IPv4 portal Web server, an IPv6 portal Web server, or both on a VLAN interface. By default, no portal Web servers are specified on a VLAN interface.

To specify a portal Web server on a service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Specify a portal Web server on the service template.	· To specify an IPv4 portal Web server: portal apply web-server server-name [ secondary ] · To specify an IPv6 portal Web server: portal ipv6 apply web-server server-name [ secondary ]	Specify an IPv4 portal Web server, an IPv6 portal Web server, or both on a service template. By default, no portal Web server is specified on a service template.

Controlling portal user access

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 hostname, source/destination IP address, TCP/UDP port number, source MAC address, access interface, and VLAN. Packets matching a portal-free rule will not trigger portal authentication, so users sending the packets can directly access the specified external websites.

When you configure portal-free rules, follow these restrictions and guidelines:

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

· If portal users have come online before source-based portal-free rules are configured, the device keeps accounting on traffic of the users even if they match these rules.

To configure an IP-based portal-free rule:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Configure an IPv4-based portal-free rule.	portal free-rule rule-number { destination ip { ip-address { mask-length \| mask } \| any } [ tcp tcp-port-number \| udp udp-port-number ] \| source ip { ip-address { mask-length \| mask } \| any } [ tcp tcp-port-number \| udp udp-port-number ] } * [ interface interface-type interface-number ]	By default, no IPv4-based portal-free rule exists.
3. Configure an IPv6-based portal-free rule.	portal free-rule rule-number { destination ipv6 { ipv6-address prefix-length \| any } [ tcp tcp-port-number \| udp udp-port-number ] \| source ipv6 { ipv6-address prefix-length \| any } [ tcp tcp-port-number \| udp udp-port-number ] } * [ interface interface-type interface-number ]	By default, no IPv6-based portal-free rule exists.

To configure a source-based portal-free rule:

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Configure a source-based portal-free rule.

portal free-rule rule-number source { ap ap-name | { interface interface-type interface-number | mac mac-address | vlan vlan-id } * }

By default, no source-based portal-free rule exists.

If you specify both a VLAN and an interface, the interface must belong to the VLAN. If the interface does not belong to the VLAN, the portal-free rule does not take effect.

To configure a destination-based portal-free rule:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Configure a destination-based portal-free rule.	portal free-rule rule-number destination host-name	By default, no destination-based portal-free rule exists.

Configuring an authentication destination subnet

By configuring authentication destination subnets, you specify that users trigger portal authentication only when they accessing the specified subnets (excluding the destination IP addresses and subnets specified in portal-free rules). Users can access other subnets without portal authentication.

You can configure multiple authentication destination subnets. If the destination subnets overlap, the subnet with the largest address scope (with the smallest mask or prefix) takes effect.

To configure an IPv4 portal authentication destination subnet:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure an IPv4 portal authentication destination subnet.	portal free-all except destination ipv4-network-address { mask-length \| mask }	By default, no IPv4 portal authentication destination subnet is configured, and users accessing any subnets must pass portal authentication.

To configure an IPv6 portal authentication destination subnet:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure an IPv6 portal authentication destination subnet.	portal ipv6 free-all except destination ipv6-network-address prefix-length	By default, no IPv6 portal authentication destination subnet is configured, and users accessing any subnets must pass portal authentication.

Setting the maximum number of portal users

Perform this task to control the total number of portal users in the system, and the maximum number of IPv4 or IPv6 portal users on a VLAN interface or service template.

When you set the maximum number of portal users, follow these restrictions and guidelines:

· If you set the maximum total number smaller than the number of current online portal users on the device, this configuration still takes effect. The online users are not affected but the system forbids new portal users to log in.

· If you set the maximum number smaller than the current number of portal users on a VLAN interface or a service template, this configuration still takes effect. The online users are not affected but the system forbids new portal users to log in from the interface or service template.

· Make sure the maximum combined number of IPv4 and IPv6 portal users specified on all VLAN interfaces or service templates does not exceed the system-allowed maximum number. Otherwise, the exceeding number of portal users will not be able to log in to the device.

To set the maximum number of total portal users allowed in the system:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the maximum number of total portal users.	portal max-user max-number	By default, no limit is set on the number of portal users in the system.

To set the maximum number of portal users on a VLAN interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Set the maximum number of portal users on the VLAN interface.	portal { ipv4-max-user \| ipv6-max-user } max-number	By default, no limit is set on the number of portal users on a VLAN interface.

To set the maximum number of portal users on a service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Set the maximum number of portal users on the service template.	portal { ipv4-max-user \| ipv6-max-user } max-number	By default, no limit is set on the number of portal users on a service template.

Specifying a portal authentication domain

An authentication domain defines a set of authentication, authorization, and accounting policies. Each portal user belongs to an authentication domain and is authenticated, authorized, and accounted in the domain.

With a portal authentication domain specified on an interface or service template, the device uses the authentication domain for AAA of all portal users on the interface or service template. This allows for flexible portal access control.

The device selects the authentication domain for a portal user in this order:

1. ISP domain specified for the interface or service template.

2. ISP domain carried in the username.

3. System default ISP domain. For information about the default ISP domain, see "Configuring AAA."

You can specify an IPv4 portal authentication domain, an IPv6 portal authentication domain, or both on an interface or on a service template.

To specify a portal authentication domain on a VLAN interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Specify a portal authentication domain on the VLAN interface.	· To specify an IPv4 portal authentication domain: portal domain domain-name · To specify an IPv6 portal authentication domain: portal ipv6 domain domain-name	By default, no ISP domain is specified for portal users on a VLAN interface.

To specify a portal authentication domain on a service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Specify a portal authentication domain on the service template.	· To specify an IPv4 portal authentication domain: portal domain domain-name · To specify an IPv6 portal authentication domain: portal ipv6 domain domain-name	By default, no ISP domain is specified for portal users on a service template.

Specifying a preauthentication domain

The preauthentication domain takes effect only on portal users with IP addresses obtained through DHCP or DHCPv6.

After you configure a preauthentication domain on a portal-enabled VLAN interface, the device authorizes users on the interface as follows:

1. After an unauthenticated user obtains an IP address, the user is assigned with authorization attributes configured for the preauthentication domain.

The authorization attributes in a preauthentication domain include ACL and user profile.

An unauthenticated user who is authorized with the authorization attributes in a preauthentication domain is called a preauthentication user.

2. After the user passes portal authentication, the user is assigned with new authorization attributes from the AAA server.

3. After the user goes offline, the user is reassigned with the authorization attributes in the preauthentication domain.

When you specify a preauthentication domain, follow these restrictions and guidelines:

· Make sure you specify an existing ISP domain as a preauthentication domain. If the specified ISP domain does not exist, the device might operate incorrectly.

· You must delete a preauthentication domain (by using the undo portal [ ipv6 ] pre-auth domain command) and reconfigure it in the following situations:

? You create the ISP domain after specifying it as the preauthentication domain.

? You delete the specified ISP domain and then re-create it.

To specify a preauthentication domain:

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 preauthentication domain.	portal [ ipv6 ] pre-auth domain domain-name	By default, no preauthentication domain is specified on an interface.

Specifying a preauthentication IP address pool for portal users

You must specify a preauthentication IP address pool on a portal-enabled VLAN interface in the following situation:

· Portal users access the network through a subinterface of the portal-enabled interface.

· The subinterface does not have an IP address.

· Portal users need to obtain IP addresses through DHCP.

After a user connects to a portal-enabled VLAN interface, the user uses an IP address for portal authentication according to the following rules:

· If the VLAN interface is configured with a preauthentication IP address pool, the user uses the following IP address:

? If the client is configured to obtain an IP address automatically through DHCP, the user obtains an address from the specified IP address pool.

? If the client is configured with a static IP address, the user uses the static IP address. However, if the interface does not have an IP address, users using static IP addresses cannot pass authentication.

· If the VLAN interface has an IP address but no preauthentication IP pool specified, the user uses the static IP address or the IP address obtained from a DHCP server.

· If the VLAN interface has no IP address or preauthentication IP pool specified, the user cannot perform portal authentication.

After the user passes portal authentication, the AAA server authorizes an IP address pool for re-assigning an IP address to the user. If no authorized IP address pool is deployed, the user continues using the previous IP address.

If the portal user does not perform authentication or fails to pass authentication, the assigned IP address is still retained.

Make sure the specified IP address pool exists and is complete. Otherwise, the user cannot obtain the IP address and cannot perform portal authentication.

To specify an IP address pool before portal authentication:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Specify a preauthentication IP address pool for portal users.	portal [ ipv6 ] pre-auth ip-pool pool-name	By default, no preauthentication IP address pool is specified on an interface.

Enabling strict-checking on portal authorization information

The strict checking mode allows a portal user to stay online only when the authorized information for the user is successfully deployed on a VLAN interface or service template.

You can enable strict checking on authorized ACLs, authorized user profiles, or both. If you enable both ACL checking and user profile checking, the user will be logged out if either checking fails.

An ACL/user profile checking fails when the authorized ACL/user profile does not exist on the device or the ACL/user profile fails to be deployed.

To enable strict-checking on portal authorization information on a VLAN interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Enable strict checking mode on portal authorization information.	portal authorization { acl \| user-profile } strict-checking	By default, the strict checking mode is disabled. In this case, the portal users stay online even when the authorized ACLs or user profiles do not exist or fail to be deployed.

To enable strict-checking on portal authorization information on a service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Enable strict checking mode on portal authorization information.	portal authorization { acl \| user-profile } strict-checking	By default, the strict checking mode is disabled. In this case, the portal users stay online even when the authorized ACLs or user profiles do not exist or fail to be deployed.

Allowing only portal clients with DHCP-assigned IP addresses to pass portal authentication

IMPORTANT:

To ensure that IPv6 portal clients can pass portal authentication when this feature is configured, disable the temporary IPv6 address feature on terminal devices. Otherwise, IPv6 portal clients will use temporary IPv6 addresses to access the IPv6 network and will fail portal authentication.

This feature allows only portal clients with DHCP-assigned IP addresses to pass portal authentication. Users with static IP addresses cannot pass portal authentication to come online. Use this feature to prevent portal clients with illegal IP addresses from accessing the network.

To configure an interface to allow only portal clients with DHCP-assigned IP addresses to pass portal authentication:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Configure the interface to allow only portal clients with DHCP-assigned IP addresses to pass portal authentication.	portal [ ipv6 ] user-dhcp-only	By default, both portal clients with DHCP-assigned IP addresses and portal clients with static IP addresses can pass portal authentication to come online.

To configure a service template to allow only portal clients with DHCP-assigned IP addresses to pass portal authentication:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Configure the service template to allow only portal clients with DHCP-assigned IP addresses to pass portal authentication.	portal [ ipv6 ] user-dhcp-only	By default, both portal clients with DHCP-assigned IP addresses and portal clients with static IP addresses can pass portal authentication to come online.

Enabling outgoing packets filtering

When you enable this feature on a portal-enabled VLAN interface or service template, the device permits the interface or service template to send the following packets:

· Packets whose destination IP addresses are IP addresses of authenticated portal users.

· Packets that match portal-free rules.

Other outgoing packets on the VLAN interface or service template are dropped.

To enable outgoing packets filtering on a portal-enabled VLAN interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Enable outgoing packets filtering.	portal [ ipv6 ] outbound-filter enable	By default, outgoing packets filtering is disabled on a portal-enabled VLAN interface. The VLAN interface can send any packets.

To enable outgoing packets filtering on a portal-enabled service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Enable outgoing packets filtering.	portal [ ipv6 ] outbound-filter enable	By default, outgoing packets filtering is disabled on a service template. The service template can send any packets.

Configuring portal detection features

Configuring online detection of portal users

Configure online detection to quickly detect abnormal logouts of portal users.

· Configure ARP or ICMP detection for IPv4 portal users.

· Configure ND or ICMPv6 detection for IPv6 portal users.

If the device receives no packets from a portal user within the idle time, the device detects the user's online status as follows:

· ICMP or ICMPv6 detection—Sends ICMP or ICMPv6 requests to the user at configurable intervals to detect the user status.

? If the device receives a reply within the maximum number of detection attempts, it considers that the user is online and stops sending detection packets. Then the device resets the idle timer and repeats the detection process when the timer expires.

? If the device receives no reply after the maximum number of detection attempts, the device logs out the user.

· ARP or ND detection—Sends ARP or ND requests to the user and detects the ARP or ND entry status of the user at configurable intervals.

? If the ARP or ND entry of the user is refreshed within the maximum number of detection attempts, the device considers that the user is online and stops detecting the user's ARP or ND entry. Then the device resets the idle timer and repeats the detection process when the timer expires.

? If the ARP or ND entry of the user is not refreshed after the maximum number of detection attempts, the device logs out the user.

To configure online detection of IPv4 portal users:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Configure online detection of IPv4 portal users.	portal user-detect type { arp \| icmp } [ retry retries ] [ interval interval ] [ idle time ]	By default, this feature is disabled on a VLAN interface.

To configure online detection of IPv6 portal users:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Configure online detection of IPv6 portal users.	portal ipv6 user-detect type { icmpv6 \| nd } [ retry retries ] [ interval interval ] [ idle time ]	By default, this feature is disabled on a VLAN interface.

Configuring portal authentication server detection

During portal authentication, if the communication between the access device and portal authentication server is broken, both of the following occur:

· New portal users are not able to log in.

· The online portal users are not able to log out 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.

With the portal authentication server detection feature, the device periodically detects portal packets sent by a portal authentication server to determine the reachability of the server. If the device receives a portal packet within a detection timeout (timeout timeout) and the portal packet is valid, the device considers the portal authentication server to be reachable. Otherwise, the device considers the portal authentication server to be unreachable.

Portal packets include user login packets, user logout packets, and heartbeat packets. Heartbeat packets are periodically sent by a server. By detecting heartbeat packets, the device can detect the server's actual status more quickly than by detecting other portal packets.

Only the IMC portal authentication server supports sending heartbeat packets. To test server reachability by detecting heartbeat packets, you must enable the server heartbeat feature on the IMC portal authentication server.

You can configure the device to take one or more of the following actions when the server reachability status changes:

· Sending a trap message to the NMS. The trap message contains the name and current state of the portal authentication server.

· Sending a log message, which contains the name, the current state, and the original state of the portal authentication server.

· Enabling portal fail-permit. When the portal authentication server is unreachable, the portal fail-permit feature on an interface allows users on the interface to have network access. When the server recovers, it resumes portal authentication on the interface. For more information, see "Configuring the portal fail-permit feature."

To configure portal authentication server detection:

Step	Command	Remarks
1. Enter system view.	system-view	N/A-
2. Enter portal authentication server view.	portal server server-name	N/A
3. Configure portal authentication server detection.	server-detect [ timeout timeout ] { log \| trap } *	By default, portal authentication server detection is disabled. This feature takes effect regardless of whether portal authentication is enabled on an interface or not. Make sure the detection timeout is greater than the portal server heartbeat interval on the portal authentication server.

Configuring portal Web server detection

A portal authentication process cannot complete if the communication between the access device and the portal Web server is broken. To address this problem, you can enable portal Web server detection on the access device.

With the portal Web server detection feature, the access device simulates a Web access process to initiate a TCP connection to the portal Web server. If the TCP connection can be established successfully, the access device considers the detection successful, and the portal Web server is reachable. Otherwise, it considers the detection to have failed. Portal authentication status on interfaces of the access device does not affect the portal Web server detection feature.

You can configure the following detection parameters:

· Detection interval—Interval at which the device detects the server reachability.

· Maximum number of consecutive failures—If the number of consecutive detection failures reaches this value, the access device considers that the portal Web server is unreachable.

You can configure the device to take one or more of the following actions when the server reachability status changes:

· Sending a trap message to the NMS. The trap message contains the name and current state of the portal Web server.

· Sending a log message, which contains the name, the current state, and the original state of the portal Web server.

· Enabling portal fail-permit. When the portal Web server is unreachable, the portal fail-permit feature on an interface allows users on the interface to have network access. When the server recovers, it resumes portal authentication on the interface. For more information, see "Configuring the portal fail-permit feature."

To configure portal Web server detection:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter portal Web server view.	portal web-server server-name	N/A
3. Configure portal Web server detection.	server-detect [ interval interval ] [ retry retries ] { log \| trap } *	By default, portal Web server detection is disabled. This feature takes effect regardless of whether portal authentication is enabled on an interface or not.

Configuring portal user synchronization

Once the access device loses communication with a portal authentication server, the portal user information on the access device and that on the portal authentication server might be inconsistent after the communication resumes. To address this problem, the device provides the portal user synchronization feature. This feature is implemented by sending and detecting portal synchronization packets, as follows:

1. The portal authentication server sends the online user information to the access device in a synchronization packet at the user heartbeat interval.

The user heartbeat interval is set on the portal authentication server.

2. Upon receiving the synchronization packet, the access device compares the users carried in the packet with its own user list and performs the following operations:

? If a user contained in the packet does not exist on the access device, the access device informs the portal authentication server to delete the user. The access device starts the synchronization detection timer (timeout timeout) immediately when a user logs in.

? If the user does not appear in any synchronization packet within a synchronization detection interval, the access device considers the user does not exist on the portal authentication server and logs the user out.

Portal user synchronization requires a portal authentication server to support the portal user heartbeat function. Only the IMC portal authentication server supports the portal user heartbeat function. To implement the portal user synchronization feature, you also need to configure the user heartbeat function on the portal authentication server. Make sure the user heartbeat interval configured on the portal authentication server is not greater than the synchronization detection timeout configured on the access device.

Deleting a portal authentication server on the access device also deletes the user synchronization configuration for the portal authentication server.

To configure portal user information synchronization:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter portal authentication server view.	portal server server-name	N/A
3. Configure portal user synchronization.	user-sync timeout timeout	By default, portal user synchronization is disabled.

Configuring the portal fail-permit feature

Perform this task to configure the portal fail-permit feature on a VLAN interface or service template. When the access device detects that the portal authentication server or portal Web server is unreachable, it allows users on the VLAN interface or service template to have network access without portal authentication.

When portal fail-permit is enabled for a portal authentication server and portal Web servers on a VLAN interface, the VLAN interface disables portal authentication in either of the following conditions:

· All portal Web servers are unreachable.

· The specified portal authentication server is unreachable.

Portal authentication resumes on the VLAN interface when the specified portal authentication server and a minimum of one portal Web server becomes reachable. After portal authentication resumes, users who failed portal authentication and unauthenticated portal users need to pass authentication to access network resources. Portal users who have passed authentication can continue accessing network resources.

The device regards the portal Web server as unreachable only if both the primary portal Web server and the back portal Web server are unreachable.

To configure portal fail-permit on a VLAN interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Enable portal fail-permit for a portal authentication server.	portal [ ipv6 ] fail-permit server server-name	By default, portal fail-permit is disabled for a portal authentication server.
4. Enable portal fail-permit for a portal Web server.	portal [ ipv6 ] fail-permit web-server	By default, portal fail-permit is disabled for portal Web servers.

To configure portal fail-permit on a service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Enable portal fail-permit for the portal Web servers specified for the service template.	portal [ ipv6 ] fail-permit web-server	By default, portal fail-permit is disabled for portal Web servers.

Configuring BAS-IP for portal packets sent to the portal authentication server

If the device runs Portal 2.0, the unsolicited packets sent to the portal authentication server must carry the BAS-IP attribute. If the device runs Portal 3.0, the unsolicited packets sent to the portal authentication server must carry the BAS-IP or BAS-IPv6 attribute.

If IPv4 portal authentication is enabled on a VLAN interface or service template, you can configure the BAS-IP attribute on the VLAN interface or service template. If IPv6 portal authentication is enabled on a VLAN interface, you can configure the BAS-IPv6 attribute on the VLAN interface.

After this attribute is configured, the source IP address for unsolicited notification portal packets the device sends to the portal authentication server is the configured BAS-IP or BAS-IPv6 address. If the attribute is not configured, the source IP address of the portal packets is the IP address of the packet output interface.

To configure the BAS-IP attribute for unsolicited portal packets sent to the portal authentication server on a VLAN interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Configure BAS-IP for IPv4 portal packets sent to the portal authentication server.	portal bas-ip ipv4-address	By default: · The BAS-IP attribute of an IPv4 portal reply packet sent to the portal authentication server is the source IPv4 address of the packet. · The BAS-IP attribute of an IPv4 portal notification packet sent to the portal authentication server is the IPv4 address of the packet's output interface.
4. Configure BAS-IPv6 for IPv6 portal packets sent to the portal authentication server.	portal bas-ipv6 ipv6-address	By default: · The BAS-IPv6 attribute of an IPv6 portal reply packet sent to the portal authentication server is the source IPv6 address of the packet. · The BAS-IPv6 attribute of an IPv6 portal notification packet sent to the portal authentication server is the IPv6 address of the packet's output interface.

To configure the BAS-IPv4 attribute for portal packets sent to the portal authentication server on a service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Configure BAS-IP for IPv4 portal packets sent to the portal authentication server.	portal bas-ip ipv4-address	By default: · The BAS-IP attribute of an IPv4 portal reply packet sent to the portal authentication server is the source IPv4 address of the packet. · The BAS-IP attribute of an IPv4 portal notification packet sent to the portal authentication server is the IPv4 address of the packet's output interface.
4. Configure BAS-IPv6 for IPv6 portal packets sent to the portal authentication server.	portal bas-ipv6 ipv6-address	By default: · The BAS-IPv6 attribute of an IPv6 portal reply packet sent to the portal authentication server is the source IPv6 address of the packet. · The BAS-IPv6 attribute of an IPv6 portal notification packet sent to the portal authentication server is the IPv6 address of the packet's output interface.

Specifying the device ID

The portal authentication server uses device IDs to identify the devices that send protocol packets to the portal server.

Make sure the configured device ID is different than any other access devices communicating with the same portal authentication server.

To specify the device ID:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Specify the device ID.	portal device-id device-id	By default, a device is not configured with a device ID.

Enabling portal roaming

Portal roaming takes effect only on portal users logging in from VLAN interfaces. It does not take effect on portal users logging in from common Layer 3 interface.

If portal roaming is enabled on a VLAN interface, an online portal user can access resources from any Layer 2 port in the VLAN without re-authentication.

If portal roaming is disabled, to access external network resources from a Layer 2 port different from the current access port in the VLAN, the user must do the following:

· First log out from the current port.

· Then re-authenticate on the new Layer 2 port.

To enable portal roaming:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable portal roaming.	portal roaming enable	By default, portal roaming is enabled.

Specifying a format for the NAS-Port-Id attribute

RADIUS servers from different vendors might require different formats of the NAS-Port-Id attribute in the RADIUS packets. You can specify the NAS-Port-Id attribute format as required.

The device supports the NAS-Port-Id attribute in format 1, format 2, format 3, and format 4. For more information about the formats, see Security Command Reference.

To specify a format for the NAS-Port-Id attribute:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Specify the format for the NAS-Port-Id attribute.	portal nas-port-id format { 1 \| 2 \| 3 \| 4 }	By default, the format for the NAS-Port-Id attribute is format 2.

Logging out online portal users

This feature deletes users that have passed portal authentication and terminates ongoing portal authentications.

When the number of online users exceeds 2000, executing the portal delete-user command takes a few minutes. To ensure successful logout of online users, do not perform the following operations during the command execution:

· Active/standby MPU switchover.

· Disabling portal authentication on the interface.

To log out online users:

Step	Command
1. Enter system view.	system-view
2. Log out IPv4 online portal users.	portal delete-user { ipv4-address \| all \| interface interface-type interface-number }
3. Log out IPv6 online portal users.	portal delete-user { all \| interface interface-type interface-number \| ipv6 ipv6-address }

Configuring Web redirect

Web redirect is a simplified portal feature. This feature redirects a user on a VLAN interface or a service template to the specified URL when the user accesses an external network through a Web browser. After the specified redirect interval, the user is redirected from the visiting website to the specified URL again.

Web redirect can provide ISPs with extended services. For example, the ISPs can place advertisements and publish information on the redirected webpage.

Web redirect takes effect only on HTTP packets that use the default port number 80.

On a service template, both Web redirect and Web redirect track can be enabled and will take effect at the same time.

To configure Web redirect on an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Configure Web redirect.	web-redirect [ ipv6 ] url url-string [ interval interval ]	By default, Web redirect is disabled.

To configure Web redirect on a service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Configure Web redirect on the service template.	web-redirect [ ipv6 ] url url-string [ interval interval ]	By default, Web redirect is disabled on a service template.

Applying a NAS-ID profile to an interface

By default, the device sends its device name in the NAS-Identifier attribute of all RADIUS requests.

For example, map the NAS-ID companyA to all VLANs of company A. The device will send companyA in the NAS-Identifier attribute for the RADIUS server to identify requests from any Company A users.

You can apply a NAS-ID profile to a portal-enabled VLAN interface. If no NAS-ID profile is specified on the VLAN interface or no matching NAS-ID is found in the specified profile, the device uses the device name as the interface NAS-ID.

To apply a NAS-ID profile to an interface:

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	By default, no NAS-ID profiles exist. For more information about this command, see Security Command Reference.
3. Configure a NAS ID and VLAN binding in the profile.	nas-id nas-identifier bind vlan vlan-id	By default, no NAS-ID and VLAN bindings exist. For more information about this command, see Security Command Reference.
4. Return to system view.	quit	N/A
5. Enter VLAN interface view.	interface interface-type interface-number	N/A
6. Specify the NAS-ID profile on the interface.	portal nas-id-profile profile-name	By default, no NAS-ID profile is specified on a VLAN interface.

Configuring the local portal Web server feature

To perform local portal authentication for users, perform the following tasks:

· Configure a local portal Web server.

· Configure a name for the portal Web server and specify a local IP address of the device as the server's URL.

· Enable portal authentication on the user access interface.

· Specify the portal Web server on the portal-enabled interface.

During local portal authentication, the local Web portal server pushes authentication pages to users. You can customize the authentication pages or use the default authentication pages.

In wireless networks, you can bind different SSIDs and endpoint types to different authentication page files for portal users. Then, the device pushes authentication pages to users according to the user's SSID and endpoint type. The device selects the authentication page to be pushed to a user in the following order:

· Authentication page bound with both the SSID and endpoint type.

· Authentication page bound with the SSID.

· Authentication page bound with the endpoint type.

· Default authentication page.

Customizing authentication pages

Authentication pages are HTML files. Local portal authentication requires the following authentication pages:

· Logon page

· Logon success page

· Logon failure page

· Online page

· System busy page

· Logoff success page

You must customize the authentication pages, including the page elements that the authentication pages will use, for example, back.jpg for authentication page Logon.htm.

Follow the authentication page customization rules when you edit the authentication page files.

File name rules

The names of the main authentication page files are fixed (see Table 5). You can define the names of the files other than the main authentication page files. File names and directory names are case insensitive.

Table 5 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	online.htm
System busy page Pushed when the system is busy or the user is in the logon process	busy.htm
Logoff success page	logoffSuccess.htm

Page request rules

The local portal Web server supports only Get and Post requests.

· Get requests—Used 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 requests—Used when users submit username and password pairs, log in, and log out.

Post request attribute rules

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

? 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 Web server.

? The username attribute is fixed as PtUser. The password attribute is fixed as PtPwd.

? The value of the PtButton attribute is either Logon or Logoff, which indicates the action that the user requests.

? A logon Post request must contain PtUser, PtPwd, and PtButton attributes.

? A logoff Post request must contain the PtButton attribute.

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

<p>Password :<input type="password" name = "PtPwd" style="width:160px;height:22px" maxlength=32>

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

Page file compression and saving rules

You must compress the authentication pages and their page elements into a standard zip file.

· The name of a zip file can contain only letters, numbers, and underscores. Do not name the zip file as defaultfile.zip because the name of the system-defined default authentication page file is defaultfile.zip.

· The authentication pages must be placed in the root directory of the zip file. Do not delete the system-defined default authentication page file defaultfile.zip in the root directory.

· Zip files can be transferred to the device through FTP or TFTP and must be saved in the root directory of the device.

Examples of zip files on the device:

<Sysname> dir

Directory of flash:

0 -rw- 1405 Feb 28 2008 15:53:31 ssid2.zip

1 -rw- 1405 Feb 28 2008 15:53:20 ssid1.zip

2 -rw- 1405 Feb 28 2008 15:53:39 ssid3.zip

3 -rw- 1405 Feb 28 2008 15:53:44 ssid4.zip

2540 KB total (1319 KB free)

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:

2. Add the function for page loading pt_init() to logonSucceess.htm.

See the contents in gray:

<html>

<head>

<title>LogonSuccessed</title>

</head>

... ...

</body>

</html>

Configuring a local portal Web server

Perform the following tasks for the local portal Web server to support HTTPS:

· Configure a PKI policy, obtain the CA certificate, and request a local certificate. For more information, see "Configuring PKI."

· Configure an SSL server policy, and specify the PKI domain configured in the PKI policy. For more information, see "Configuring SSL."

To configure a local portal Web server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a local portal Web server and enter its view.	portal local-web-server { http \| https [ ssl-server-policy policy-name ] [ tcp-port port-number ] }	By default, no local portal Web servers exist.
3. Specify the default authentication page file for the local portal Web server.	default-logon-page filename	By default, a set of default authentication pages exists.
4. (Optional.) Configure the listening TCP port for the local portal Web server.	tcp-port port-number	By default, the HTTP service listening port number is 80 and that for HTTPS is the TCP port number set by using the portal local-web-server command. If not set by the portal local-web-server command, the HTTPS service listening port number is 443.
5. (Optional.) Bind a device type, endpoint name, or SSID to an authentication page file.	logon-page bind { device-type { computer \| pad \| phone } \| device-name device-name \| ssid ssid-name } * file file-name	By default, no device type, endpoint name, or SSID is bound to an authentication page file.

Enabling validity check on wireless clients

Enable this feature when portal authentication is enabled on the service template. In wireless networks where the AP forwards client traffic, the AC does not have ARP entries for clients. Therefore, the AC cannot check the validity of portal clients by using ARP entries. To ensure that valid users can perform portal authentication, you must enable wireless client validity check on the AC.

This feature enables the AC to validate a client by looking up the client information in the WLAN snooping table, DHCP snooping table, and ARP table. If the client information exists, the AC determines the client to be valid for portal authentication.

To enable validity check on wireless clients:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable validity check on wireless clients.	portal host-check enable	By default, the device checks wireless portal client validity according to ARP entries only.

Automatically logging out wireless portal users

With this feature enabled, the device automatically logs out portal users after the wireless clients are disconnected from the network.

To automatically log out portal users after wireless clients are disconnected from the network:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable automatic logout for wireless portal users.	portal user-logoff after-client-offline enable	By default, the device does not log out portal users automatically after the wireless clients are disconnected from the network.

Enabling ARP or ND entry conversion for portal clients

This feature converts the ARP or ND entries to Rule ARP or ND entries for portal users. Rule ARP or ND entries will not be aged and they will be deleted immediately when the portal users go offline.

When this feature is disabled, ARP or ND entries for portal users are dynamic entries and will be aged when their respective aging timers expire. Rule ARP or ND entries created before the feature is disabled still exist until the portal users go offline.

This feature is enabled by default. If a user logs out and then tries to get online before the ARP or ND entry is relearned for the user, the user will fail the authentication. Therefore, in scenarios where portal users might get online and offline frequently in a short time, disable this feature to avoid immediate deletion of the ARP or ND entries when users go offline.

Enabling or disabling of this feature takes effect only on portal users who pass authentication after the feature is enabled or disabled.

To configure ARP or ND entry conversion for portal clients:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable ARP or ND entry conversion for portal clients.	portal refresh { arp \| nd } enable	By default, ARP or ND entry conversion is disabled for portal clients.
3. Disable ARP or ND entry conversion for portal clients.	undo portal refresh { arp \| nd } enable	By default, ARP or ND entry conversion is disabled for portal clients.

Configuring HTTPS redirect

The device can redirect HTTPS requests to the portal Web server for portal authentication. During SSL connection establishment, the user browser might display a message that it cannot verify server identity by certificate. For users to perform portal authentication without checking such a message, configure an SSL server policy to request a client-trusted certificate on the device. The name of the policy must be https_redirect. For information about SSL server policy configuration, see "Configuring SSL." For information about certificate request, see "Configuring PKI."

To configure HTTPS redirect:

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

By default, no SSL server policies exist on the device.

The name of the SSL server policy for HTTPS redirect must be https_redirect.

For more information about this command, see Security Command Reference.

Configuring MAC-based quick portal authentication

To configure MAC-based quick portal authentication, complete the following configuration on the device:

· Configure a remote or local MAC binding servers.

· Specify a MAC binding server on a VLAN interface or a service template.

Configuring a remote MAC binding server

You can configure multiple remote MAC binding servers on the device.

Perform this task to configure MAC binding server parameters, such as the server's IP address and the free-traffic threshold.

To configure a remote MAC binding server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a MAC binding server and enter its view.	portal mac-trigger-server server-name	By default, no MAC binder servers exist.
3. Specify the IP address of the MAC binding server.	ip ipv4-address [ key { cipher \| simple } string ]	By default, the IP address of a MAC binding server is not specified.
4. (Optional.) Specify the free-traffic threshold.	free-traffic threshold value	By default, the free-traffic threshold is 0 bytes.
5. (Optional.) Specify the NAS-Port-Type value carried in RADIUS requests sent to the RADIUS server.	nas-port-type value	By default, the NAS-Port-Type value carried in RADIUS requests is 0.
6. (Optional.) Set the UDP port number the MAC binding server uses to listen for MAC binding query packets.	port port-number	By default, the MAC binding server listens for MAC binding query packets on UDP port 50100.
7. (Optional.) Specify the maximum number of attempts and the interval for sending MAC binding queries to the MAC binding server.	binding-retry { retries \| interval interval } *	By default, the maximum number of query attempts is 3 and the query interval is 1 second.
8. (Optional.) Specify the type of the MAC binding server	server-type { cmcc \| imc }	By default, the type of a MAC binding server is IMC.
9. (Optional.) Specify the version of the portal protocol.	version version-number	By default, the version of the portal protocol is 1.
10. (Optional.) Specify the timeout the device waits for portal authentication to complete after receiving the MAC binding query response.	authentication-timeout minutes	By default, the portal authentication timeout time is 3 minutes.
11. (Optional.) Set the aging time for MAC-trigger entries.	aging-time seconds	By default, the aging time for MAC-trigger entries is 300 seconds.
12. (Optional.) Enable AAA failure unbinding.	aaa-fail nobinding enable	By default, AAA failure unbinding is disabled.

Configuring a local MAC binding server

In local MAC-trigger authentication, the access device acts as a local MAC binding server to perform local portal authentication on portal users. You can configure multiple local MAC binding servers, which are independent with each other.

To configure a local MAC binding server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a MAC binding server and enter its view.	portal mac-trigger-server server-name	By default, no MAC binder servers exist.
3. Enable local MAC-trigger authentication.	local-binding enable	By default, local MAC-trigger authentication is disabled.
4. (Optional.) Set the free-traffic threshold.	free-traffic threshold value	By default, the free-traffic threshold is 0 bytes.
5. (Optional.) Set the aging time for local MAC-account binding entries.	local-binding aging-time hours	By default, the aging time for local MAC-account binding entries is 12 hours..
6. (Optional.) Set the aging time for MAC-trigger entries.	aging-time seconds	By default, the aging time for MAC-trigger entries is 300 seconds.
7. (Optional.) Enable AAA failure unbinding.	aaa-fail nobinding enable	By default, AAA failure unbinding is disabled.

Specifying a MAC binding server on a VLAN interface

After a MAC binding server is specified on a VLAN interface, the device can implement MAC-based quick portal authentication for portal users on the VLAN interface.

To specify a MAC binding server on a VLAN interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Specify a MAC binding server on the VLAN interface.	portal apply mac-trigger-server server-name	By default, no MAC binding server is specified on a VLAN interface.

Specifying a MAC binding server on a service template

After a MAC binding server is specified on a service template, the device can implement MAC-based quick portal authentication for portal users using the service template.

To specify a MAC binding server on a service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Specify a MAC binding server on the service template.	portal apply mac-trigger-server server-name	By default, no MAC binding server is specified on a service template.

Configuring NAS-Port-Type

The NAS-Port-Type attribute carried in RADIUS requests represents the user's access interface type. When a portal user log in from a VLAN interface or a service template, the value of the NAS-Port-Type attribute is as follows:

· If the NAS-Port-Type is configured, the NAS-Port-Type value is the configured value.

· If the NAS-Port-Type is not configured, the NAS-Port-Type value is the user's access interface type obtained by the access device.

As the access device, the BAS might not be able to correctly obtain a user's interface type when multiple network devices exist between the BAS and the portal client. For example, the access interface type obtained by the BAS for a wireless portal user might be the type of the wired interface that authenticated the user. For the BAS to send correct user interface type to the RADIUS server, perform this task to specify the correct NAS-Port-Type value.

To configure NAS-Port-Type on a VLAN interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Configure the NAS-Port-Type value.	portal nas-port-type { ethernet \| wireless }	By default, the portal NAS-Port-Type value carried in RADIUS requests is the user's access interface type value obtained by the access device.

To configure NAS-Port-Type on a service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Configure the NAS-Port-Type value.	portal nas-port-type { ethernet \| wireless }	By default, the portal NAS-Port-Type value carried in RADIUS requests is the user's access interface type value obtained by the access device.

Configuring portal safe-redirect

Portal safe-redirect filters HTTP requests by HTTP request method, browser type (in HTTP User Agent), and destination URL, and redirects only the permitted HTTP requests. This reduces the risk that the portal Web server cannot respond to HTTP requests because of overload.

Table 6 Browser types supported by portal safe-redirect

Browser type	Description
Safari	Apple browser
Chrome	Google browser
Firefox	Firefox browser
UC	UC browser
QQBrowser	QQ browser
LBBROWSER	Cheetah browser
TaoBrowser	Taobao browser
Maxthon	Maxthon browser
BIDUBrowser	Baidu browser
MSIE 10.0	Microsoft IE 10.0 browser
MSIE 9.0	Microsoft IE 9.0 browser
MSIE 8.0	Microsoft IE 8.0 browser
MSIE 7.0	Microsoft IE 7.0 browser
MSIE 6.0	Microsoft IE 6.0 browser
MetaSr	Sogou browser

To configure portal safe-redirect:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable portal safe-redirect.	portal safe-redirect enable	By default, the portal safe-redirect feature is disabled.
3. (Optional.) Specify HTTP request methods permitted by portal safe-redirect.	portal safe-redirect method { get \| post } *	By default, the device can redirect only HTTP requests with GET method after portal safe-redirect is enabled.
4. (Optional.) Specify a browser type permitted by portal safe-redirect.	portal safe-redirect user-agent user-agent-string	By default, no browser types are specified. The device can redirect HTTP requests sent by all supported browsers (see Table 6) after portal safe-redirect is enabled.
5. (Optional.) Configure a URL forbidden by portal safe-redirect.	portal safe-redirect forbidden-url user-url-string	By default, no forbidden URLs are configured. The device can redirect HTTP requests with any URLs.
6. (Optional.) Configure a filename extension forbidden by portal safe-redirect.	portal safe-redirect forbidden-file filename-extension	By default, no forbidden filename extensions are configured. The device redirects HTTP requests regardless of the file extension in the URL.

Setting the interval at which an AP reports traffic statistics to the AC

When the client traffic forwarding location is at APs, an AP reports traffic statistics to the AC at a regular interval.

To set the interval at which an AP reports traffic statistics to the AC:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the interval at which an AP reports traffic statistics to the AC.	portal client-traffic-report interval interval	By default, an AP reports traffic statistics to the AC every 60 seconds.

Excluding an attribute from portal protocol packets

Support of the portal authentication server for portal protocol attributes varies by the server type. If the device sends the portal authentication server a packet that contains an attribute unsupported by the server, the device and the server cannot communicate.

To address this issue, you can configure portal protocol packets to not carry the attributes unsupported by the portal authentication server.

To exclude an attribute from portal protocol packets for a portal authentication server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter portal authentication server view.	portal server server-name	N/A
3. Exclude an attribute from portal protocol packets.	exclude-attribute number { ack-auth \| ntf-logout \| ack-logout }	By default, no attributes are excluded from portal protocol packets.

To exclude an attribute from portal protocol packets for a MAC binding server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter MAC binding server view.	portal mac-trigger-server server-name	N/A
3. Exclude an attribute from portal protocol packets.	exclude-attribute attribute-number	By default, no attributes are excluded from portal protocol packets.

Enabling portal logging

To help with security audits, you can enable portal logging to record portal authentication information.

For portal log messages to be sent correctly, you must also configure the information center on the device. For more information about information center configuration, see Network Management and Monitoring Configuration Guide.

To enable portal logging:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable logging for portal user logins and logouts.	portal user log enable	By default, portal user login and logout logging is disabled.
3. Enable logging for portal protocol packets.	portal packet log enable	By default, portal protocol packet logging is disabled.
4. Enable logging for portal redirect.	portal redirect log enable	By default, portal redirect logging is disabled.

Configuring portal support for third-party authentication

IMPORTANT:

This feature is restricted to Hong Kong and Macao.

You can configure the device to support QQ authentication or email authentication as third-party authentication for portal. Users can use QQ or email accounts to complete portal authentication instead of using a dedicated portal account. No portal authentication servers are required to be deployed, and no local portal users are required to be created on the device. This reduces the management and maintenance cost.

Editing buttons and pages for third-party authentication

To use third-party authentication for portal users, you must add a QQ or email authentication button to the portal logon page. After a portal user clicks the QQ or email authentication button on the portal logon page, the user is redirected to the QQ or email authentication page.

Editing a third-party authentication button on the logon page

Edit a third-party authentication button on the portal logon page (logon.htm). For more information about editing portal authentication pages, see "Customizing authentication pages."

When you edit the QQ authentication button, you must call the pt_getQQSubmitUrl() function to get the URL of the QQ authentication page.

The following example shows part of the script of the QQ authentication button.

<html>

<head>

<title>Logon</title>

function setQQUrl(){

document.getElementById("qqurl").href = pt_getQQSubmitUrl();

}

</script>

</head>

<body>

... ...

... ...

</body>

</html>

No special requirements exist in the process of editing an email authentication button.

Editing a third-party authentication page

You only need to edit the email authentication page. The QQ authentication page is provided by Tencent.

When you edit the email authentication page, follow the rules in "Customizing authentication pages" and the following rules:

· Set the action attribute of the beginning form tag to maillogin.html. Otherwise, the device cannot send the user information

· Save the login page as emailLogon.htm.

The following example shows part of the script of the emailLogon.htm page.

<p>Password :<input type="password" name = "PtPwd" style="width:160px;height:22px" maxlength=32>

</form>

Configuring a third-party authentication server

Configuring the QQ authentication server

To use QQ authentication for portal users, you must go to the Tencent Open Platform (http://connect.qq.com/intro/login) to finish the following tasks:

1. Register as a developer by using a valid QQ account.

2. Apply the access to the platform for your website. The website is the webpage to which users are redirected after passing QQ authentication.

You will obtain the APP ID and APP key from the Tencent Open Platform after your application succeeds.

After a portal user passes QQ authentication, the QQ authentication server sends the authorization code of the user to the portal Web server. After the portal Web server receives the authorization code, it sends the authorization code of the user, the APP ID, and the APP key to the QQ authentication server for verification. If the information is verified as correct, the device determines that the user passes QQ authentication.

To configure the QQ authentication server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a QQ authentication server and enter its view.	portal extend-auth-server qq	By default, no QQ authentication server exists.
3. Specify the URL of the QQ authentication server.	auth-url url-string	By default, the URL of QQ authentication server is https://graph.qq.com.
4. Specify the URL to which portal users are redirected after they pass QQ authentication.	redirect-url url-string	By default, portal users are redirected to URL http://lvzhou.h3c.com/portal/qqlogin.html after they pass QQ authentication. The redirection URL must be the same as that specified during website application on the Tencent Open Platform.
5. Specify the APP ID for QQ authentication.	app-id app-id	By default, an APP ID for QQ authentication exists.
6. Specify the APP key for QQ authentication.	app-key app-key	By default, an APP key for QQ authentication exists.

Configuring the email authentication server

If a user chooses email authentication, the user can access the network after passing email authentication.

To configure the email authentication server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an email authentication server and enter its view.	portal extend-auth-server mail	By default, no email authentication server exists.
3. Specify protocols for email authentication.	mail-protocol { imap \| pop3 } *	By default, no protocols are specified for email authentication.
4. Specify an email domain name for email authentication.	mail-domain-name string	By default, no email domain names are specified for email authentication.

Specifying an authentication domain for third-party authentication

You must specify an authentication domain for third-party authentication. Make sure the authentication, authorization, and accounting methods in the authentication domain for portal users are none.

To specify an authentication domain for third-party authentication on a VLAN interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Specify an authentication domain for third-party authentication.	portal extend-auth domain domain-name	By default, no authentication domain is specified for third-party authentication.

To specify an authentication domain for third-party authentication on a service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Specify an authentication domain for third-party authentication.	portal extend-auth domain domain-name	By default, no authentication domain is specified for third-party authentication.

Configuring portal temporary pass

Typically, a portal user cannot access the Internet before passing portal authentication. This feature allows a user to access the Internet temporarily if the user uses a WeChat account to perform portal authentication. During the temporary pass period, the user can provide WeChat authentication information to the WeChat server for the server to interact with the access device to finish portal authentication.

To configure portal temporary pass on a VLAN interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VLAN interface view.	interface interface-type interface-number	N/A
3. Enable portal temporary pass and set the temporary pass period.	portal temp-pass [ period period-value ] enable	By default, portal temporary pass is disabled.

To configure portal temporary pass on a service template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Enable portal temporary pass and set the temporary pass period.	portal temp-pass [ period period-value ] enable	By default, portal temporary pass is disabled.

Configuring the portal authentication monitoring feature

The portal authentication monitoring feature records portal user offlines, authentication failures, and authentication errors. These records help the administrator quickly identify causes of authentication faults.

To configure the portal authentication monitoring feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable portal user offline recording.	portal logout-record enable	By default, portal user offline recording is disabled.
3. Set the maximum number of portal user offline records.	portal logout-record max number	By default, the maximum number of portal user offline records is 32000.
4. Export portal user offline records to a path.	portal logout-record export url url-string [ start-time start-date start-time end-time end-date end-time ]	N/A
5. Enable portal authentication failure recording.	portal auth-fail-record enable	By default, portal authentication failure recording is disabled.
6. Set the maximum number of portal authentication failure records.	portal auth-fail-record max number	By default, the maximum number of portal authentication failure records is 32000.
7. Export portal authentication failure records to a path.	portal auth-fail-record export url url-string [ start-time start-date start-time end-time end-date end-time ]	N/A
8. Enable portal authentication error recording.	portal auth-error-record enable	By default, portal authentication error recording is disabled.
9. Set the maximum number of portal authentication error records.	portal auth-error-record max number	By default, the maximum number of portal authentication error records is 32000.
10. Export portal authentication error records to a path.	portal auth-error-record export url url-string [ start-time start-date start-time end-time end-date end-time ]	N/A

Setting the user synchronization interval for portal authentication using OAuth

If portal authentication uses OAuth, the device periodically reports user information to the portal authentication server for user synchronization on the server. To disable user synchronization from the device to the portal authentication server, set the user synchronization interval to 0 seconds on the device.

To set the user synchronization interval for portal authentication using OAuth:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the user synchronization interval for portal authentication using OAuth.	portal oauth user-sync interval interval	By default, the user synchronization interval is 60 seconds.

Logging out wireless portal users that switch SSIDs

This feature enables the device to log out portal users on the original service template when they switch SSIDs so that they can pass authentication on the new service template.

To log out wireless portal users that switch SSIDs:

Task	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the device to log out wireless portal users that switch SSIDs.	portal user-logoff ssid-switch enable	By default, the device does not log out wireless portal users that switch SSIDs and the users stay online.

Displaying and maintaining portal

Execute display commands in any view and the reset command in user view.

Task	Command
Display portal authentication error records.	display portal auth-error-record { all \| ipv4 ipv4-address \| ipv6 ipv6-address \| start-time start-date start-time end-time end-date end-time }
Display portal authentication failure records.	display portal auth-fail-record { all \| ipv4 ipv4-address \| ipv6 ipv6-address \| start-time start-date start-time end-time end-date end-time \| username username }
Display packets statistics for portal captive-bypass.	display portal captive-bypass statistics [ slot slot-number ]
Display IP addresses corresponding to host names in destination-based portal-free rules.	display portal dns free-rule-host [ host-name ]
Display information about third-party authentication servers.	display portal extend-auth-server { all \| qq \| mail }
Display portal configuration and portal running state information.	display portal { ap ap-name [ radio radio-id ] \| interface interface-type interface-number }
Display information about local MAC-account binding entries.	display portal local-binding mac-address { mac-address \| all }
Display portal user offline records.	display portal logout-record { all \| ipv4 ipv4-address \| ipv6 ipv6-address \| start-time start-date start-time end-time end-date end-time \| username username }
Display packet statistics for portal authentication servers.	display portal packet statistics [ extend-auth-server { cloud \| mail \| qq \| wechat } \| mac-trigger-server server-name \| server server-name ]
Display statistics for portal permit rules.	display portal permit-rule statistics
Display portal redirect packet statistics.	display portal redirect statistics [ slot slot-number ]
Display portal filtering rules.	display portal rule { all \| dynamic \| static } { ap ap-name [ radio radio-id ] \| interface interface-type interface-number [ slot slot-number ] }
Display packet statistics for portal safe-redirect.	display portal safe-redirect statistics [ slot slot-number ]
Display portal authentication server information.	display portal server [ server-name ]
Display portal user information.	display portal user { all \| ap ap-name [ radio radio-id ] \| auth-type { cloud \| email \| local \| mac-trigger \| normal \| qq \| wechat } \| interface interface-type interface-number \| ip ip-address \| ipv6 ipv6-address \| mac mac-address \| pre-auth [ interface interface-type interface-number \| ip ip-address \| ipv6 ipv6-address \| username username ] } [ brief \| verbose ]
Display the number of portal users.	display portal user count
Display portal Web server information.	display portal web-server [ server-name ]
Display information about MAC binding servers.	display mac-trigger-server { all \| name server-name }
Display Web redirect rule information.	display web-redirect rule interface interface-type interface-number [ slot slot-number ]
Clear portal authentication error records.	reset portal auth-error-record { all \| ipv4 ipv4-address \| ipv6 ipv6-address \| start-time start-date start-time end-time end-date end-time }
Clear portal authentication failure records.	reset portal auth-fail-record { all \| ipv4 ipv4-address \| ipv6 ipv6-address \| start-time start-date start-time end-time end-date end-time \| username username }
Clear packets statistics for portal captive-bypass.	reset portal captive-bypass statistics [ slot slot-number ]
Clear portal user offline records.	reset portal logout-record { all \| ipv4 ipv4-address \| ipv6 ipv6-address \| start-time start-date start-time end-time end-date end-time \| username username }
Clear local MAC-account binding entries.	reset portal local-binding mac-address { mac-address \| all }
Clear packet statistics for portal authentication servers.	reset portal packet statistics [ extend-auth-server { cloud \| mail \| qq \| wechat } \| mac-trigger-server server-name \| server server-name ] *
Clear packet statistics for portal redirect.	reset portal redirect statistics [ slot slot-number ]
Clear packet statistics for portal safe-redirect.	reset portal safe-redirect statistics [ slot slot-number ]

Portal configuration examples

Configuring portal authentication on a VLAN interface

Network requirements

As shown in Figure 43, the client is connected to the AC through the AP. The client is assigned with a public IP address either manually or through DHCP. A portal server acts as both a portal authentication server and a portal Web server. A RADIUS server acts as the authentication/accounting server.

Configure portal authentication, so the client can access only the portal server before passing the authentication and access Internet resources after passing the authentication.

Figure 43 Network diagram

Configuration prerequisites

· Configure IP addresses for the client, AC, and servers as shown in Figure 43 and make sure they can reach each other.

· Configure the RADIUS server correctly to provide authentication and accounting functions.

Configuring the portal authentication server on IMC PLAT 5.0

In this example, the portal server runs on IMC PLAT 5.0(E0101) and IMC UAM 5.0(E0101).

1. Configure the portal authentication server:

a. Log in to IMC and click the Service tab.

b. Select User Access Manager > Portal Service Management > Server from the navigation tree to enter the portal server configuration page, as shown in Figure 44.

c. Configure the portal server parameters as needed.

This example uses the default settings.

d. Click OK.

Figure 44 Portal server configuration

2. Configure the IP address group:

a. Select User Access Manager > Portal Service Management > IP Group from the navigation tree to enter the portal IP address group configuration page.

b. Click Add to enter the page shown in Figure 45.

c. Enter the IP group name.

d. Enter the start IP address and end IP address of the IP group.

Make sure the client IP address is in the IP group.

e. Select a service group.

This example uses the default group Ungrouped.

f. Select the action Normal.

g. Click OK.

Figure 45 Adding an IP address group

3. Add a portal device:

a. Select User Access Manager > Portal Service Management > Device from the navigation tree to enter the portal device configuration page.

b. Click Add to enter the page shown in Figure 46.

c. Enter the device name NAS.

d. Enter the IP address of the AC's interface connected to the client.

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 portal authentication, and therefore select No from the Reallocate IP list.

g. Select whether to support server heartbeat and user heartbeat functions.

In this example, select No for both Support Server Heartbeat and Support User Heartbeat.

h. Click OK.

Figure 46 Adding a portal device

4. Associate the portal device with the IP address group:

a. As shown in Figure 47, click the icon in the Port Group Information Management column of device NAS to enter the port group configuration page.

b. Click Add to enter the page shown in Figure 48.

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.

Figure 47 Device list

Figure 48 Adding a port group

5. Select User Access Manager > Service Parameters > Validate System Configuration from the navigation tree 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

# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.

[AC-radius-rs1] primary authentication 192.168.0.112

[AC-radius-rs1] primary accounting 192.168.0.112

[AC-radius-rs1] key authentication simple radius

[AC-radius-rs1] key accounting simple radius

# Exclude the ISP domain name from the username sent to the RADIUS server.

[AC-radius-rs1] user-name-format without-domain

[AC-radius-rs1] quit

# Enable RADIUS session control.

[AC] radius session-control enable

2. Configure an authentication domain:

# Create an ISP domain named 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] accounting portal radius-scheme rs1

[AC-isp-dm1] quit

# Configure domain dm1 as the default ISP domain. If a user enters the username without the ISP domain name at login, the authentication and accounting methods of the default domain are used for the user.

[AC] domain default enable dm1

3. Configure portal authentication:

# Configure a portal authentication server.

[AC] portal server newpt

[AC-portal-server-newpt] ip 192.168.0.111 key simple portal

[AC-portal-server-newpt] port 50100

[AC-portal-server-newpt] quit

# Configure a portal Web server.

[AC] portal web-server newpt

[AC-portal-websvr-newpt] url http://192.168.0.111:8080/portal

[AC-portal-websvr-newpt] quit

# Enable portal authentication on VLAN-interface 100.

[AC] interface vlan-interface 100

[AC–Vlan-interface100] portal enable method direct

# Reference the portal Web server newpt on VLAN-interface 100.

[AC–Vlan-interface100] portal apply web-server newpt

# Configure the BAS-IP as 2.2.2.1 for portal packets sent from VLAN-interface 100 to the portal authentication server.

[AC–Vlan-interface100] portal bas-ip 2.2.2.1

[AC–Vlan-interface100] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.

[AC] display portal interface vlan-interface 100

Portal information of Vlan-interface100

NAS-ID profile: Not configured

Authorization : Strict checking

ACL : Disabled

User profile : Disabled

IPv4:

Portal status: Enabled

Portal authentication method: Direct

Portal Web server: newpt(active)

Secondary portal Web server: Not configured

Authentication domain: Not configured

Pre-auth domain: Not configured

User-dhcp-only: Disabled

Pre-auth IP pool: Not configured

Max portal users: Not configured

Bas-ip: 2.2.2.1

User Detection: Not configured

Action for server detection:

Server type Server name Action

-- -- --

Layer3 source network:

IP address Mask

Destination authenticate subnet:

IP address Mask

IPv6:

Portal status: Disabled

Portal authentication method: Disabled

Portal Web server: Not configured

Secondary portal Web server: Not configured

Authentication domain: Not configured

Pre-auth domain: Not configured

User-dhcp-only: Disabled

Pre-auth IP pool: Not configured

Max portal users: Not configured

Bas-ipv6: Not configured

User detection: Not configured

Action for server detection:

Server type Server name Action

-- -- --

Layer3 source network:

IP address Prefix length

Destination authenticate subnet:

IP address Prefix length

A user can perform portal authentication by using the H3C iNode client or through Web page. Before passing the authentication, the user can access only the authentication page http://192.168.0.111:8080/portal. All Web requests from the user will be redirected to the authentication page. After passing the authentication, the user can access Internet resources.

# After the user passes authentication, use the following command to display information about the portal user.

[AC] display portal user interface vlan-interface 100

Total portal users: 1

Username: abc

Portal server: newpt

State: Online

VPN instance: N/A

MAC IP VLAN Interface

0015-e9a6-7cfe 2.2.2.2 100 Vlan-interface100

Authorization information:

DHCP IP pool: N/A

User profile: N/A

ACL: N/A

Configuring portal authentication on a service template

Network requirements

As shown in Figure 49, the AP directly forwards user traffic from the client. The client is assigned with a public IP address either manually or through DHCP. A portal server acts as both a portal authentication server and a portal Web server. A RADIUS server acts as the authentication/accounting server.

Configure portal authentication, so the client can access only the portal Web server before passing the authentication and access Internet resources after passing the authentication.

Figure 49 Network diagram

Configuration prerequisites

· Configure IP addresses for the client, AC, and servers as shown in Figure 49 and make sure they can reach each other.

· Configure the RADIUS server correctly to provide authentication and accounting functions.

· Configure the AP to make sure the AP can communicate with the AC.

Configuring the portal server on IMC PLAT 5.0

In this example, the portal server runs on IMC PLAT 5.0(E0101) and IMC UAM 5.0(E0101).

1. Configure the portal authentication server:

a. Log in to IMC and click the Service tab.

b. Select User Access Manager > Portal Service Management > Server from the navigation tree to enter the portal server configuration page, as shown in Figure 50.

c. Configure the portal server parameters as needed.

This example uses the default settings.

d. Click OK.

Figure 50 Portal server configuration

2. Configure the IP address group:

a. Select User Access Manager > Portal Service Management > IP Group from the navigation tree to enter the portal IP address group configuration page.

b. Click Add to enter the page shown in Figure 51.

Figure 51 Adding an IP address group

c. Enter the IP group name.

d. Enter the start IP address and end IP address of the IP group.

Make sure the host IP address is in the IP group.

e. Select a service group.

This example uses the default group Ungrouped.

f. Select the action Normal.

g. Click OK.

3. Add a portal device:

a. Select User Access Manager > Portal Service Management > Device from the navigation tree to enter the portal device configuration page.

b. Click Add to enter the page shown in Figure 52.

c. Enter the device name NAS.

d. Enter the IP address of the AC's interface that exchanges information with the portal server.

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 portal authentication, and therefore select No from the Reallocate IP list.

g. Select whether to support server heartbeat and user heartbeat functions.

In this example, select No for both Support Server Heartbeat and Support User Heartbeat.

h. Click OK.

Figure 52 Adding a portal device

4. Associate the portal device with the IP address group:

a. As shown in Figure 53, click the icon in the Port Group Information Management column of device NAS to enter the port group configuration page.

Figure 53 Device list

b. Click Add to enter the page shown in Figure 54.

Figure 54 Adding a port group

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.

5. Select User Access Manager > Service Parameters > Validate System Configuration from the navigation tree 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

# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.

[AC-radius-rs1] primary authentication 192.168.0.112

[AC-radius-rs1] primary accounting 192.168.0.112

[AC-radius-rs1] key authentication simple radius

[AC-radius-rs1] key accounting simple radius

# Exclude the ISP domain name from the username sent to the RADIUS server.

[AC-radius-rs1] user-name-format without-domain

[AC-radius-rs1] quit

# Enable RADIUS session control.

[AC] radius session-control enable

2. Configure an authentication domain:

# Create an ISP domain named 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] accounting portal radius-scheme rs1

[AC-isp-dm1] quit

[AC] domain default enable dm1

3. Configure portal authentication:

# Configure a portal authentication server.

[AC] portal server newpt

[AC-portal-server-newpt] ip 192.168.0.111 key simple portal

[AC-portal-server-newpt] port 50100

[AC-portal-server-newpt] quit

# Configure a portal Web server.

[AC] portal web-server newpt

[AC-portal-websvr-newpt] url http://192.168.0.111:8080/portal

[AC-portal-websvr-newpt] quit

# Create the manual AP ap2, and specify the AP model and serial ID.

[AC] wlan ap ap2 model WA536-WW

[AC-wlan-ap-ap2] serial-id 219801A1NQB117012935

# Create service template newst, set the SSID to portal 1.

[AC] wlan service-template newst

[AC–wlan-st-newst] ssid portal_1

# Enable authentication on service template newst.

[AC–wlan-st-newst] portal enable method direct

# Specify the portal Web server newpt on service template newst.

[AC–wlan-st-newst] portal apply web-server newpt

# Configure the BAS-IP as 192.168.0.110 for portal packets sent from the AC to the portal authentication server.

[AC–wlan-st-newst] portal bas-ip 192.168.0.110

# Configure the AP to forward client data traffic.

[AC–wlan-st-newst] client forwarding-location ap

# Enable service template newst.

[AC–wlan-st-newst] service-template enable

[AC–wlan-st-newst] quit

# Set the working channel to channel 11 for radio 2 of the AP.

[AC] wlan ap ap2

[AC-wlan-ap-ap2] radio 2

[AC-wlan-ap-ap2-radio-2] channel 11

# Enable radio 2 and bind service template newst and VLAN 2 to radio 2.

[AC-wlan-ap-ap2-radio-2] radio enable

[AC-wlan-ap-ap2-radio-2] service-template newst vlan 2

[AC-wlan-ap-ap2-radio-2] quit

[AC-wlan-ap-ap2] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.

[AC] display portal ap ap2

Portal information of ap2

Radio ID: 2

SSID: portal_1

Authorization : Strict checking

ACL : Disable

User profile : Disable

IPv4:

Portal status: Enabled

Portal authentication method: Direct

Portal Web server: newpt(active)

Secondary portal Web server: Not configured

Authentication domain: Not configured

User-dhcp-only: Disabled

Max portal users: Not configured

Bas-ip: 192.168.0.110

Action for server detection:

Server type Server name Action

-- -- --

Destination authentication subnet:

IP address Mask

IPv6:

Portal status: Disabled

Portal authentication method: Disabled

Portal Web server: Not configured

Secondary portal Web server: Not configured

Authentication domain: Not configured

User-dhcp-only: Disabled

Max portal users: Not configured

Bas-ipv6: Not configured

Action for server detection:

Server type Server name Action

-- -- --

Destination authentication subnet:

IP address Prefix length

# After the user passes authentication, use the following command to display information about the portal user.

[AC] display portal user ap ap2

Total portal users: 1

Username: 1

AP name: ap2

Radio ID: 2

SSID: portal_1

Portal server: newpt

State: Online

VPN instance: N/A

MAC IP VLAN Interface

0015-005e-9398 2.2.2.2 2 WLAN-BSS1/0/1

Authorization information:

DHCP IP pool: N/A

User profile: N/A

ACL number: N/A

Configuring extended portal authentication

Network requirements

As shown in Figure 55, the client is connected to the AC through the AP. The client is assigned with a public IP address either manually or through DHCP. A portal server acts as both a portal authentication server and a portal Web server. A RADIUS server acts as the authentication/accounting server.

Configure extended portal authentication. If the client fails security check after passing identity authentication, it can access only subnet 192.168.0.0/24. After passing security check, the client can access Internet resources.

Figure 55 Network diagram

Configuration prerequisites

· Configure IP addresses for the client, AC, and servers as shown in Figure 55 and make sure they can reach each other.

· Configure the RADIUS server correctly to provide authentication and accounting functions.

Configuration procedure

Perform the following tasks on the AC.

1. Configure a RADIUS scheme:

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

<AC> system-view

[AC] radius scheme rs1

# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.

[AC-radius-rs1] primary authentication 192.168.0.112

[AC-radius-rs1] primary accounting 192.168.0.112

[AC-radius-rs1] key accounting simple radius

[AC-radius-rs1] key authentication simple radius

[AC-radius-rs1] user-name-format without-domain

[AC-radius-rs1] quit

# Specify the security policy server.

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

[AC-radius-rs1] quit

# Enable RADIUS session control.

[AC] radius session-control enable

# Specify a session-control client with IP address 192.168.0.113 and plaintext shared key 12345.

[AC] radius session-control client ip 192.168.0.113 key simple 12345

2. Configure an authentication domain:

# Create an ISP domain named 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] accounting portal radius-scheme rs1

[AC-isp-dm1] quit

[AC] domain default enable dm1

3. Configure ACL 3000 as the isolation ACL and ACL 3001 as the security ACL.

[AC] acl advanced 3000

[AC-acl-ipv4-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255

[AC-acl-ipv4-adv-3000] rule deny ip

[AC-acl-ipv4-adv-3000] quit

[AC] acl advanced 3001

[AC-acl-ipv4-adv-3001] rule permit ip

[AC-acl-ipv4-adv-3001] quit

NOTE:

Make sure you specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL on the security policy server.

4. Configure portal authentication:

# Configure a portal authentication server.

[AC] portal server newpt

[AC-portal-server-newpt] ip 192.168.0.111 key simple portal

[AC-portal-server-newpt] port 50100

[AC-portal-server-newpt] quit

# Configure a portal Web server.

[AC] portal web-server newpt

[AC-portal-websvr-newpt] url http://192.168.0.111:8080/portal

[AC-portal-websvr-newpt] quit

# Enable portal authentication on VLAN-interface 100.

[AC] interface vlan-interface 100

[AC–Vlan-interface100] portal enable method direct

# Reference the portal Web server newpt on VLAN-interface 100.

[AC–Vlan-interface100] portal apply web-server newpt

# Configure the BAS-IP as 2.2.2.1 for portal packets sent from VLAN-interface 100 to the portal authentication server.

[AC–Vlan-interface100] portal bas-ip 2.2.2.1

[AC–Vlan-interface100] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.

[AC] display portal interface vlan-interface 100

Portal information of Vlan-interface100

NAS-ID profile: Not configured

Authorization : Strict checking

ACL : Disabled

User profile : Disabled

IPv4:

Portal status: Enabled

Portal authentication method: Direct

Portal Web server: newpt(active)

Secondary portal Web server: Not configured

Authentication domain: Not configured

Pre-auth domain: Not configured

User-dhcp-only: Disabled

Pre-auth IP pool: Not configured

Max portal users: Not configured

Bas-ip: 2.2.2.1

User Detection: Not configured

Action for server detection:

Server type Server name Action

-- -- --

Layer3 source network:

IP address Mask

Destination authenticate subnet:

IP address Mask

IPv6:

Portal status: Disabled

Portal authentication method: Disabled

Portal Web server: Not configured

Secondary portal Web server: Not configured

Authentication domain: Not configured

Pre-auth domain: Not configured

User-dhcp-only: Disabled

Pre-auth IP pool: Not configured

Max portal users: Not configured

Bas-ipv6: Not configured

User detection: Not configured

Action for server detection:

Server type Server name Action

-- -- --

Layer3 source network:

IP address Prefix length

Destination authenticate subnet:

IP address Prefix length

Before passing portal authentication, a user that uses the H3C iNode client can access only the authentication page http://192.168.0.111:8080/portal. All Web requests from the user will be redirected to the authentication page.

· The user can access the resources permitted by ACL 3000 after passing only identity authentication.

· The user can access Internet resources permitted by ACL 3001 after passing both identity authentication and security check.

# After the user passes identity authentication and security check, use the following command to display information about the portal user.

[AC] display portal user interface vlan-interface 100

Total portal users: 1

Username: abc

Portal server: newpt

State: Online

VPN instance: N/A

MAC IP VLAN Interface

0015-e9a6-7cfe 2.2.2.2 100 Vlan-interface100

Authorization information:

DHCP IP pool: N/A

User profile: N/A

ACL: 3001

Configuring portal server detection

Network requirements

As shown in Figure 56, the client is connected to the AC through the AP. The client is assigned with a public IP address either manually or through DHCP. A portal server acts as both a portal authentication server and a portal Web server. A RADIUS server acts as the authentication/accounting server.

· Configure portal authentication on the AC, so the client can access only the portal server before passing the authentication and access Internet resources after passing the authentication.

· Configure the AC to detect the reachability state of the portal authentication server, send log messages upon state changes, and disable portal authentication when the authentication server is unreachable.

Figure 56 Network diagram

Configuration prerequisites and guidelines

· Configure IP addresses for the AC and servers as shown in Figure 56 and make sure the client, AC, and servers can reach each other.

· Configure the RADIUS server correctly to provide authentication and accounting functions.

· Configure the portal authentication server. Be sure to enable the server heartbeat function.

· Configure the AC as follows:

? Configure portal authentication on VLAN-interface 100, the interface to which the client is connected.

? Configure portal authentication server detection, so that the AC can detect the reachability of the portal authentication server by cooperating with the portal server heartbeat function.

Configuring the portal authentication server on IMC PLAT 5.0

In this example, the portal server runs on IMC PLAT 5.0(E0101) and IMC UAM 5.0(E0101).

1. Configure the portal authentication server:

a. Log in to IMC and click the Service tab.

b. Select User Access Manager > Portal Service Management > Server from the navigation tree to enter the portal server configuration page, as shown in Figure 57.

c. Configure the portal server heartbeat interval.

d. Use the default settings for other parameters.

e. Click OK.

Figure 57 Portal authentication server configuration

2. Configure the IP address group:

a. Select User Access Manager > Portal Service Management > IP Group from the navigation tree to enter the portal IP address group configuration page.

b. Click Add to enter the page shown in Figure 58.

c. Enter the IP group name.

d. Enter the start IP address and end IP address of the IP group.

Make sure the client IP address is in the IP group.

e. Select a service group.

This example uses the default group Ungrouped.

f. Select the action Normal.

g. Click OK.

Figure 58 Adding an IP address group

3. Add a portal device:

a. Select User Access Manager > Portal Service Management > Device from the navigation tree to enter the portal device configuration page.

b. Click Add to enter the page shown in Figure 59.

c. Enter the device name NAS.

d. Enter the IP address of the AC's interface connected to the client.

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 portal authentication, and therefore select No from the Reallocate IP list.

g. Select whether to support server heartbeat function.

In this example, select Yes for Support Server Heartbeat.

h. Click OK.

Figure 59 Adding a portal device

4. Associate the portal device with the IP address group:

a. As shown in Figure 60, click the icon in the Port Group Information Management column of device NAS to enter the port group configuration page.

b. Click Add to enter the page shown in Figure 61.

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.

Figure 60 Device list

Figure 61 Adding a port group

5. Select User Access Manager > Service Parameters > Validate System Configuration from the navigation tree 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

# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.

[AC-radius-rs1] primary authentication 192.168.0.112

[AC-radius-rs1] primary accounting 192.168.0.112

[AC-radius-rs1] key authentication simple radius

[AC-radius-rs1] key accounting simple radius

# Exclude the ISP domain name from the username sent to the RADIUS server.

[AC-radius-rs1] user-name-format without-domain

[AC-radius-rs1] quit

# Enable RADIUS session control.

[AC] radius session-control enable

2. Configure an authentication domain:

# Create an ISP domain named 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] accounting portal radius-scheme rs1

[AC-isp-dm1] quit

[AC] domain default enable dm1

3. Configure portal authentication:

# Configure a portal authentication server.

[AC] portal server newpt

[AC-portal-server-newpt] ip 192.168.0.111 key simple portal

[AC-portal-server-newpt] port 50100

# Configure reachability detection of the portal authentication server: set the server detection interval to 40 seconds, and send log messages upon reachability status changes.

[AC-portal-server-newpt] server-detect timeout 40 log

NOTE:

The value of timeout must be greater than or equal to the portal server heartbeat interval.

# Configure a portal Web server.

[AC] portal web-server newpt

[AC-portal-websvr-newpt] url http://192.168.0.111:8080/portal

[AC-portal-websvr-newpt] quit

# Enable portal authentication on VLAN-interface 100.

[AC] interface vlan-interface 100

[AC–Vlan-interface100] portal enable method direct

# Enable portal fail-permit for the portal authentication server newpt.

[AC–Vlan-interface100] portal fail-permit server newpt

# Reference the portal Web server newpt on VLAN-interface 100.

[AC–Vlan-interface100] portal apply web-server newpt

# Configure the BAS-IP as 2.2.2.1 for portal packets sent from VLAN-interface 100 to the portal authentication server.

[AC–Vlan-interface100] portal bas-ip 2.2.2.1

[AC–Vlan-interface100] quit

Verifying the configuration

# Use the following command to display information about the portal authentication server.

[AC] display portal server newpt

Portal server: newpt

IP : 192.168.0.111

VPN instance : Not configured

Port : 50100

Server Detection : Timeout 40s Action: log

User synchronization : Not configured

Status : Up

The Up status of the portal authentication server indicates that the portal authentication server is reachable. If the access device detects that the portal authentication server is unreachable, the Status field in the command output displays Down. The access device generates a server unreachable log "Portal server newpt turns down from up." and disables portal authentication on the access interface, so the client can access the external network without authentication.

Configuring portal authentication using local portal Web server

Network requirements

As shown in Figure 62, the client is connected to the AC through the AP. The client is assigned with a public IP address either manually or through DHCP. The AC acts as both a portal authentication server and a portal Web server. A RADIUS server acts as the authentication/accounting server.

Configure portal authentication on the AC. Before a user passes portal authentication, the user can access only the local portal Web server. After passing portal authentication, the user can access other network resources.

Figure 62 Network diagram

Configuration prerequisites and guidelines

· Configure IP addresses for the client, AC, and server as shown in Figure 62 and make sure they can reach each other.

· Configure the RADIUS server correctly to provide authentication and accounting functions.

· Customize the authentication pages, compress them to a file, and upload the file to the root directory of the storage medium of the AC.

Configuration procedure

1. Configure a RADIUS scheme:

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

<AC> system-view

[AC] radius scheme rs1

# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.

[AC-radius-rs1] primary authentication 192.168.0.112

[AC-radius-rs1] primary accounting 192.168.0.112

[AC-radius-rs1] key authentication simple radius

[AC-radius-rs1] key accounting simple radius

# Exclude the ISP domain name from the username sent to the RADIUS server.

[AC-radius-rs1] user-name-format without-domain

[AC-radius-rs1] quit

# Enable RADIUS session control.

[AC] radius session-control enable

2. Configure an authentication domain:

# Create an ISP domain named 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] accounting portal radius-scheme rs1

[AC-isp-dm1] quit

[AC] domain default enable dm1

3. Configure portal authentication:

# Create a local portal Web server. Use HTTP to exchange authentication information with clients.

[AC] portal local-web-server http

# Specify file abc.zip as the default authentication page file for local portal authentication. (Make sure the file exists under the root directory of the AC.)

[AC–portal-local-websvr-http] default-logon-page abc.zip

# Set the HTTP service listening port number to 2331 for the local portal Web server.

[AC–portal-local-webserver-http] tcp-port 2331

[AC–portal-local-websvr-http] quit

# Configure the portal Web server name as newpt and URL as the IP address of the portal authentication-enabled interface or a loopback interface (except 127.0.0.1).

[AC] portal web-server newpt

[AC-portal-websvr-newpt] url http://2.2.2.1:2331/portal

[AC-portal-websvr-newpt] quit

# Enable portal authentication on VLAN-interface 100.

[AC] interface vlan-interface 100

[AC–Vlan-interface100] portal enable method direct

# Specify the portal Web server newpt on VLAN-interface 100.

[AC–Vlan-interface100] portal apply web-server newpt

[AC–Vlan-interface100] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.

[AC] display portal interface vlan-interface 100

Portal information of Vlan-interface 100

Authorization Strict checking

ACL Disabled

User profile Disabled

IPv4:

Portal status: Enabled

Portal authentication method: Direct

Portal Web server: newpt(active)

Secondary portal Web server: Not configured

Authentication domain: Not configured

Pre-auth domain: Not configured

User-dhcp-only: Disabled

Pre-auth IP pool: Not configured

Max portal users: Not configured

Bas-ip: Not configured

User Detection: Not configured

Action for server detection:

Server type Server name Action

-- -- --

Layer3 source network:

IP address Mask

Destination authenticate subnet:

IP address Mask

IPv6:

Portal status: Disabled

Portal authentication method: Disabled

Portal Web server: Not configured

Secondary portal Web server: Not configured

Authentication domain: Not configured

Pre-auth domain: Not configured

User-dhcp-only: Disabled

Pre-auth IP pool: Not configured

Max portal users: Not configured

Bas-ipv6: Not configured

User detection: Not configured

Action for server detection:

Server type Server name Action

-- -- --

Layer3 source network:

IP address Prefix length

Destination authenticate subnet:

IP address Prefix length

A user can perform portal authentication through Web page. Before passing the authentication, the user can access only the authentication page http://2.2.2.1:2331/portal and all Web requests will be redirected to the authentication page. After passing the authentication, the user can access Internet resources.

# After the user passes authentication, use the following command to display information about the portal user.

[AC] display portal user interface vlan-interface 100

Total portal users: 1

Username: abc

Portal server: newpt

State: Online

VPN instance: --

MAC IP VLAN Interface

0015-e9a6-7cfe 2.2.2.2 -- Vlan-interface100

Authorization information:

IP pool: N/A

User profile: N/A

ACL: N/A

Configuring remote MAC-based quick portal authentication

Network requirements

As shown in Figure 63, the AP directly forwards user traffic from the client. The client is assigned with a public IP address either manually or through DHCP. A portal server acts as a portal authentication server, a portal Web server, and a MAC binding server. A RADIUS server acts as the authentication/accounting server.

Configure remote MAC-based quick portal authentication to meet the following requirements:

· A user can access the network without portal authentication before the user's network traffic reaches 1024000 bytes.

· The client can pass portal authentication without entering a username or password after the user passes portal authentication for the first time.

Figure 63 Network diagram

Configuration prerequisites

· Configure IP addresses for the client, AC, and servers as shown in Figure 63 and make sure they can reach each other.

· Configure the RADIUS server correctly to provide authentication and accounting functions.

· Make sure the AP can communicate with the AC.

Configuring the portal server on IMC PLAT 7.1

In this example, the portal server runs on IMC PLAT 7.1(E0303), IMC EIA 7.1(F0303), and IMC EIP 7.1(F0303).

1. Configure the portal authentication server:

a. Log in to IMC and click the User tab.

b. Select User Access Policy > Portal Service > Server from the navigation tree to enter the portal server configuration page, as shown in Figure 64.

c. Configure the portal server parameters as needed.

This example uses the default values.

d. Click OK.

Figure 64 Portal authentication server configuration

2. Configure the IP address group:

a. Select User Access Policy > Portal Service > IP Group from the navigation tree to enter the portal IP address group configuration page.

b. Click Add to enter the page shown in Figure 65.

c. Enter the IP group name.

d. Enter the start IP address and end IP address of the IP group.

Make sure the client IP address (2.2.2.2) is in the IP group.

e. Select a service group.

This example uses the default group Ungrouped.

f. Select Normal from the Action list.

g. Click OK.

Figure 65 Adding an IP address group

3. Add a portal device:

a. Select User Access Policy > Portal Service > Device from the navigation tree to enter the portal device configuration page.

b. Click Add to enter the page shown in Figure 66.

c. Enter the device name.

d. Enter the IP address of the AC's interface that exchanges information with the portal server.

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

f. Enter the key, which must be the same as that configured on the AC.

g. Select Directly Connected for Access Method.

h. Click OK.

Figure 66 Adding a portal device

4. Associate the portal device with the IP address group:

a. As shown in Figure 67, click the Port Group Information Management icon for device NAS to enter the port group configuration page.

Figure 67 Device list

a. Click Add to enter the page shown in Figure 68.

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. Select Supported for Transparent Authentication.

f. Use the default settings for other parameters.

g. Click OK.

Figure 68 Adding a port group

5. Select User Access Policy > Service Parameters > Validate System Configuration from the navigation tree to validate the configurations.

Configuring the MAC binding server on IMC PLAT 7.1

In this example, the MAC binding server runs on IMC PLAT 7.1(E0303), IMC EIA 7.1(F0303), and IMC EIP 7.1(F0303).

1. Add an access policy:

a. Select User Access Policy > Access Policy from the navigation tree to enter the access policy page.

b. Click Add to enter the page shown in Figure 69.

c. Enter the access policy name.

d. Select a service group.

e. Use the default settings for other parameters.

f. Click OK.

Figure 69 Adding an access policy

2. Add an access service:

a. Select User Access Policy > Access Service from the navigation tree to enter the access service page.

b. Click Add to enter the page shown in Figure 70.

c. Enter the service name.

d. Select the Transparent Authentication on Portal Endpoints option.

e. Use the default settings for other parameters.

f. Click OK.

Figure 70 Adding an access service

3. Add an access user:

a. Select Access User > All Access Users from the navigation tree to enter the access user page.

b. Click Add to enter the page shown in Figure 71.

c. Select an access user.

d. Set the password.

e. Select a value from the Max. Transparent Portal Bindings list.

f. Click OK.

Figure 71 Adding an access user

4. Configure system parameters:

a. Select User Access Policy > Service Parameters > System Settings from the navigation tree to enter the system settings page.

b. Click the Configure icon for User Endpoint Settings to enter the page shown in Figure 72.

c. Select whether to enable transparent portal authentication on non-smart devices.

In this example, select Enable for Non-Terminal Authentication.

d. Click OK.

Figure 72 Configuring user endpoint settings

e. click the Configure icon for Endpoint Aging Time to enter the page shown in Figure 73.

f. Set the endpoint aging time as needed.

This example uses the default value.

Figure 73 Setting the endpoint aging time

5. Select User Access Policy > Service Parameters > Validate System Configuration from the navigation tree 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

# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.

[AC-radius-rs1] primary authentication 192.168.0.112

[AC-radius-rs1] primary accounting 192.168.0.112

[AC-radius-rs1] key authentication simple radius

[AC-radius-rs1] key accounting simple radius

# Exclude the ISP domain name from the username sent to the RADIUS server.

[AC-radius-rs1] user-name-format without-domain

[AC-radius-rs1] quit

# Enable RADIUS session control.

[AC] radius session-control enable

2. Configure an authentication domain:

# Create an ISP domain named 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] accounting portal radius-scheme rs1

[AC-isp-dm1] quit

[AC] domain default enable dm1

3. Configure portal authentication:

# Configure a portal authentication server.

[AC] portal server newpt

[AC-portal-server-newpt] ip 192.168.0.111 key simple portal

[AC-portal-server-newpt] port 50100

[AC-portal-server-newpt] quit

# Configure a portal Web server.

[AC] portal web-server newpt

[AC-portal-websvr-newpt] url http://192.168.0.111:8080/portal

[AC-portal-websvr-newpt] quit

# Enable validity check on the wireless client.

[AC] portal host-check enable

# Create the service template st1, set the SSID to st1, and create VLAN 100 on the service template.

[AC] wlan service-template st1

[AC-wlan-st-st1] ssid st1

[AC-wlan-st-st1] vlan 100

# Enable authentication on the service template st1.

[AC–wlan-st-st1] portal enable method direct

# Specify the portal Web server newpt on the service template st1.

[AC–wlan-st-st1] portal apply web-server newpt

[AC-wlan-st-st1] quit

4. Configure MAC-based quick portal authentication:

# Create the MAC binding server mts.

[AC] portal mac-trigger-server mts

# Set the free-traffic threshold for portal users to 1024000 bytes.

[AC-portal-mac-trigger-server-mts] free-traffic threshold 1024000

# Specify the IP address of the MAC binding server as 192.168.0.111.

[AC-portal-mac-trigger-server-mts] ip 192.168.0.111

[AC-portal-mac-trigger-server-mts] quit

# Specify the MAC binding server mts on the service template st1.

[AC] wlan service-template st1

[AC-wlan-st-st1] portal apply mac-trigger-server mts

# Enable the service template st1.

[AC-wlan-st-st1] service-template enable

[AC-wlan-st-st1] quit

Verifying the configuration

# Display information about the MAC binding server.

[AC] display portal mac-trigger-server name mts

Portal mac-trigger server: mts

Version : 1.0

Server type : IMC

IP : 192.168.0.111

Port : 50100

VPN instance : Not configured

Aging time : 300 seconds

Free-traffic threshold : 1024000 bytes

NAS-Port-Type : Not configured

Binding retry times : 3

Binding retry interval : 1 seconds

Authentication timeout : 3 minutes

A user can perform portal authentication by using the H3C iNode client or through webpage. Before passing the authentication, the user can access only the authentication page http://192.168.0.111:8080/portal. All Web requests from the user will be redirected to the authentication page. After passing the authentication, the user can access other network resources.

For the first portal authentication, the user is required to enter the username and password. When the user goes offline and then accesses the network again, the user does not need to enter the authentication username and password.

# Display portal user information.

[AC] display portal user all

Total portal users: 1

Username: Client1

AP name: ap1

Radio ID: 1

SSID:st1

Portal server: newpt

State: Online

VPN instance: N/A

MAC IP VLAN Interface

0015-e9a6-7cfe 2.2.2.2 100 WLAN-BSS1/0/1

Authorization information:

DHCP IP pool: N/A

User profile: N/A

ACL: N/A

Configuring local MAC-based quick portal authentication

Network requirements

As shown in Figure 74, the client accesses the WLAN through the AP. The client is assigned a public IP address either manually or through DHCP. The AC acts as a portal authentication server, a portal Web server, and a MAC binding server.

Configure local MAC-based quick portal authentication to meet the following requirements:

· A user can access the network without portal authentication before the user's network traffic reaches 1024000 bytes.

· The client can pass portal authentication without entering a username or password within 24 hours after the user passes portal authentication for the first time.

Figure 74 Network diagram

Configuration prerequisites

· Configure IP addresses for the client and AC as shown in Figure 74 and make sure they can reach each other.

· Make sure the AP can communicate with the AC.

Configuration procedure

1. Configure an authentication domain:

# Create an ISP domain named dm1.

<AC> system-view

[AC] domain dm1

# Configure local authentication, authorization, and accounting for portal users in ISP domain dm1.

[AC-isp-dm1] authentication portal local

[AC-isp-dm1] authorization portal local

[AC-isp-dm1] accounting portal local

[AC-isp-dm1] quit

# Configure ISP domain dm1 as the default ISP domain.

[AC] domain default enable dm1

2. Configure portal authentication:

# Create a portal Web server newpt and configure the URL for the portal Web server as http://192.168.0.111/portal.

[AC] portal web-server newpt

[AC-portal-websvr-newpt] url http://192.168.0.111/portal

[AC-portal-websvr-newpt] quit

# Enable validity check on wireless portal clients.

[AC] portal host-check enable

# Create a service template named st1.

[AC] wlan service-template st1

[AC-wlan-st-st1] ssid st1

# Enable IPv4 portal authentication on service template st1.

[AC-wlan-st-st1] portal enable method direct

# Specify portal Web server newpt on service template st1 for portal authentication.

[AC-wlan-st-st1] portal apply web-server newpt

[AC-wlan-st-st1] quit

3. Configure local MAC-based quick portal authentication:

# Create a MAC binding server named mts.

[AC] portal mac-trigger-server mts

# Enable local MAC-based quick portal authentication.

[AC-portal-mac-trigger-server-mts] local-binding enable

# Set the free-traffic threshold for portal users to 1024000 bytes.

[AC-portal-mac-trigger-server-mts] free-traffic threshold 1024000

# Set the aging time of local MAC-account binding entries to 24 hours.

[AC-portal-mac-trigger-server-mts] local-binding aging-time 24

[AC-portal-mac-trigger-server-mts] quit

# Specify MAC binding server mts for service template st1.

[AC] wlan service-template st1

[AC-wlan-st-st1] portal apply mac-trigger-server mts

# Enable service template st1.

[AC-wlan-st-st1] service-template enable

[AC-wlan-st-st1] quit

# Create a local portal Web server. Use HTTP to exchange authentication information with clients.

[AC] portal local-web-server http

# Specify file default.zip as the default authentication page file for portal authentication. (Make sure that the file exists under the root directory of the AC.)

[AC–portal-local-websvr-http] default-logon-page default.zip

[AC–portal-local-websvr-http] quit

4. Configure a local user:

# Create a network access user named client1 and set the password for the user to password in plaintext form.

[AC] local-user client1 class network

[AC-luser-network-client1] password simple password

[AC-luser-network-client1] quit

Verifying the configuration

# Display information about MAC binding server mts.

[AC] display portal mac-trigger-server name mts

Portal mac-trigger server: mts

Version : 1.0

Server type : IMC

IP : 192.168.0.111

Port : 50100

VPN instance : Not configured

Aging time : 300 seconds

Free-traffic threshold : 1024000 bytes

NAS-Port-Type : Not configured

Binding retry times : 3

Binding retry interval : 1 seconds

Authentication timeout : 3 minutes

Local-binding : Enabled

Local-binding aging-time : 24 hours

A user can perform portal authentication by using the H3C iNode client or a Web browser. Before passing the authentication, the user can access only the authentication page http://192.168.0.111/portal. All Web requests from the user will be redirected to the authentication page. After passing the authentication, the user can access other network resources.

# Display information about local MAC-trigger entries.

[AC] display portal local-binding mac-address all

Total mac-address number: 1

Mac-address User-name

0800-2700-b43a client1

# Display information about portal users on VLAN-interface 100.

[AC] display portal user interface vlan-interface100

Total portal users: 1

Username: client1

Portal server: N/A

State: Online

VPN instance: N/A

MAC IP VLAN Interface

0800-2700-b43a 192.168.0.56 100 WLAN-BSS1/0/1

Authorization information:

DHCP IP pool: N/A

User profile: N/A

ACL: N/A

Troubleshooting portal

No portal authentication page is pushed for users

Symptom

When a user is redirected to the IMC portal authentication server, no portal authentication page or error message is prompted for the user. The login page is blank.

Analysis

The key configured on the portal access device and that configured on the portal authentication server are inconsistent. As a result, packet verification fails, and the portal authentication server refuses to push the authentication page.

Solution

Use the display portal server command on the access device to check whether a key is configured for the portal authentication server.

· If no key is configured, configure the right key.

· If a key is configured, use the ip or ipv6 command in the portal authentication server view to correct the key, or correct the key configured for the access device on the portal authentication server.

Cannot log out portal users on the access device

Symptom

You cannot use the portal delete-user command on the access device to log out a portal user, but the portal user can log out by clicking the Disconnect button on the portal authentication client.

Analysis

When you execute the portal delete-user command on the access device to log out a user, the access device sends an unsolicited logout notification message to the portal authentication server. The destination port number in the logout notification is the listening port number of the portal authentication server configured on the access device. If this listening port number is not the actual listening port number configured on the server, the server cannot receive the notification. As a result, the server does not log out the user.

When a user uses the Disconnect button on the authentication client to log out, the portal authentication server sends an unsolicited logout request message to the access device. The access device uses the source port in the logout request as the destination port in the logout ACK message. As a result, the portal authentication server can definitely receive the logout ACK message and log out the user.

Solution

1. Use the display portal server command to display the listening port of the portal authentication server configured on the access device.

2. Use the portal server command in system view to change the listening port number to the actual listening port of the portal authentication server.

Cannot log out portal users on the RADIUS server

Symptom

The access device uses the H3C IMC server as the RADIUS server to perform identity authentication for portal users. You cannot log out the portal users on the RADIUS server.

Analysis

The H3C IMC server uses session control packets to send disconnection requests to the access device. On the access device, the listening UDP port for session control packets is disabled by default. Therefore, the access device cannot receive the portal user logout requests from the RADIUS server.

Solution

On the access device, execute the radius session-control enable command in system view to enable the RADIUS session control function.

Users logged out by the access device still exist on the portal authentication server

Symptom

After you log out a portal user on the access device, the user still exists on the portal authentication server.

Analysis

When you execute the portal delete-user command on the access device to log out a user, the access device sends an unsolicited logout notification to the portal authentication server. If the BAS-IP or BAS-IPv6 address carried in the logout notification is different from the portal device IP address specified on the portal authentication server, the portal authentication server discards the logout notification. When sending of the logout notifications times out, the access device logs out the user. However, the portal authentication server does not receive the logout notification successfully, and therefore it regards the user is still online.

Solution

Configure the BAS-IP or BAS-IPv6 attribute on the interface enabled with portal authentication. Make sure the attribute value is the same as the portal device IP address specified on the portal authentication server.

Configuring user profiles

Overview

A user profile saves a set of predefined parameters.

The user profile application allows flexible traffic policing on a per-user basis. Each time a user passes authentication, the device automatically applies the parameters in the user profile to this user.

The user profile restricts authenticated user behavior as follows:

1. After the authentication server verifies a user, the server sends the device the name of the user profile specified for the user.

2. The device applies the parameters in the user profile to the user.

3. When the user logs out, the device automatically removes the user profile parameters.

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

Configuration restrictions and guidelines

When you configure user profiles, follow these restrictions and guidelines:

· Configure authentication parameters before you create a user profile. The user profile supports working with 802.1X, portal, PPP, and MAC authentication methods.

· Specify a user profile for each user account:

? In remote authentication, specify a user profile on the authentication server.

? In local authentication, specify a user profile in the local user view. For information about local users, see "Configuring AAA."

Configuring a user profile

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a user profile and enter user profile view.	user-profile profile-name	You can use the command to enter the view of an existing user profile.

Displaying and maintaining user profiles

Execute display commands in any view.

Task	Command
Display configuration and online user information for the specified user profile or all user profiles.	display user-profile [ name profile-name ] [ slot slot-number ]

User profile configuration example

Network requirements

As shown in Figure 75, the AC is connected to the RADIUS server through a Layer 2 switch.

Configure the AC to meet the following requirements:

· MAC authentication is used.

· MAC-authenticated users access the wireless network through the specified AP.

Figure 75 Network diagram

Configuration procedure

Before configuring the AC, make sure:

· The AC and the RADIUS server can reach each other.

· An account with username 123 and password aaa_maca has been added on the RADIUS server.

1. Configure a RADIUS scheme:

# Create a RADIUS scheme named imcc.

<AC> system-view

[AC] radius scheme imcc

# Specify the primary authentication server.

[AC-radius-imcc] primary authentication 10.18.1.88 1812

# Specify the primary accounting server.

[AC-radius-imcc] primary accounting 10.18.1.88 1813

# Set the authentication key to 12345678 in plaintext form.

[AC-radius-imcc] key authentication simple 12345678

# Set the accounting key to 12345678 in plaintext form.

# Exclude domain names from the usernames sent to the RADIUS server.

[AC-radius-imcc] user-name-format without-domain

[AC-radius-imcc] quit

2. Configure AAA methods for an ISP domain:

# Create an ISP domain named imc.

[AC] domain imc

# Apply RADIUS scheme imcc to ISP domain imc for authentication, authorization, and accounting.

[AC-isp-imc] authentication lan-access radius-scheme imcc

[AC-isp-imc] authorization lan-access radius-scheme imcc

[AC-isp-imc] accounting lan-access radius-scheme imcc

[AC-isp-imc] quit

3. Configure MAC authentication:

# Specify username 123 and password aaa_maca in plain text for the account shared by MAC authentication users.

[AC] mac-authentication user-name-format fixed account 123 password simple aaa_maca

# Configure SSID maca_imc for wireless service template maca_imc.

[AC] wlan service-template maca_imc

[AC-wlan-st-maca_imc] ssid maca_imc

# Set the authentication mode to MAC authentication.

[AC-wlan-st-maca_imc] client-security authentication-mode mac

# Specify the ISP domain imc for the service template.

[AC-wlan-st-maca_imc] mac-authentication domain imc

# Enable the service template.

[AC-wlan-st-maca_imc] service-template enable

[AC-wlan-st-maca_imc] quit

4. Configure the manual AP ap1, and bind the service template to an AP radio:

# Create a manual AP named ap1, and specify the AP model and serial ID.

[AC] wlan ap ap1 model WA536-WW

[AC-wlan-ap-ap1] serial-id 219801A1NQB117012935

# Configure channel 149 as the working channel for radio 1 of the AP, and enable radio 1.

[AC-wlan-ap-ap1] radio 1

[AC-wlan-ap-ap1-radio-1] channel 149

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

# Bind the service template maca_imc to radio 1.

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

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

[AC-wlan-ap-ap1] quit

5. Configure a user profile:

# Create an AP group named macauth1, and add AP ap1 to the AP group.

[AC] wlan ap-group macauth1

[AC-wlan-ap-group-macauth1] ap ap1

[AC-wlan-ap-group-macauth1] quit

# Create a user profile named mac1, and specify AP group macauth1 as the permitted AP group for client access.

[AC] user-profile mac1

[AC-user-profile-mac1] wlan permit-ap-group macauth1

[AC-user-profile-mac1] quit

6. Configure the RADIUS server on IMC 7.0:

NOTE:

In this example, the RADIUS server runs on IMC PLAT 7.2 and IMC EIA 7.2.

# Add the AC to IMC EIA as an access device.

Log in to IMC, click the User tab, and select User Access Policy > Access Device Management > Access Device from the navigation tree. Then, click Add to configure an access device as follows:

a. Set the shared key for secure RADIUS communication to 12345678.

b. Select the access device from the device list or manually add the access device (with the IP address 10.18.1.1).

c. Leave the default settings for other parameters and click OK.

Figure 76 Adding the AC as an access device

# Add an access policy.

a. Click the User tab, and select User Access Policy > Access Policy from the navigation tree. Then, click Add to configure an access policy.

b. Set the policy name to aaa_maca, and use default settings for other parameters.

Figure 77 Adding an access policy

# Add an access service.

a. Click the User tab, and select User Access Policy > Access Service from the navigation tree. Then, click Add to configure an access service.

b. Set the service name to aaa_maca, and specify access policy aaa_maca as the default access policy.

Figure 78 Adding an access service

# Add an access user.

Click the User tab, and select Access User > All Access Users from the navigation tree. Then, click Add to configure an access user as follows:

a. Enter username 123.

b. Enter account name 123 and password aaa_maca.

c. Select access service aaa_maca.

Figure 79 Adding an access user

Verifying the configuration

# Display information about online MAC authentication users.

[AC] display mac-authentication connection

Total connections: 1

User MAC address : 0452-f33a-02fa

AP name : ap1

Radio ID : 1

SSID : maca_imc

BSSID : 741f-4a35-7b40

Username : 123

Authentication domain : imc

Initial VLAN : 1

Authorization VLAN : N/A

Authorization ACL number : N/A

Authorization user profile : mac1

Termination action : Default

Session timeout period : 86400 s

Online from : 2016/06/23 20:42:00

Online duration : 0h 0m 21s

# Display client information.

[AC] display wlan client

Total number of clients : 1

MAC address Username AP name R IP address VLAN

0452-f33a-02fa 123 ap1 1 10.18.1.100 1

Configuring password control

Overview

Password control allows you to implement the following features:

· Manage login and super password setup, expirations, and updates for device management users.

· Control user login status based on predefined policies.

Local users are divided into two types: device management users and network access users. This feature applies only to device management users. For more information about local users, see "Configuring AAA."

Password setting

Minimum password length

You can define the minimum length of user passwords. If a user enters a password that is shorter than the minimum length, the system rejects the password.

Password composition policy

A password can be a combination of characters from the following 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-control composition 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 7.

Table 7 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
Level 3	Three	One
Level 4	Four	One

All the combination levels are available for a password.

When a user sets or changes a password, the system checks if the password meets the combination requirement. If not, the operation fails.

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 ensure that 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 configuration will fail.

You can apply 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.

· A minimum of three identical consecutive characters is not allowed. For example, password a111 is not complex enough.

Password updating and expiration

Password updating

This feature allows you to set the minimum interval at which users can change their passwords. If a user logs in to change the password but the time passed 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 user cannot change the password twice within 48 hours.

The set minimum interval is not effective when a user is prompted to change the password at the first login or after its password aging time expires.

Password expiration

Password expiration imposes a lifecycle on a user password. After the password expires, the user needs to change the password.

If a user enters an expired password when logging in, the system displays an error message. The user is prompted to provide a new password and to confirm it by entering it again. The new password must be valid, and the user must enter exactly the same password when confirming it.

Telnet users, SSH users, and console users can change their own passwords. The administrator must change passwords for FTP users.

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 users, SSH users, and console users can change their own passwords. The administrator must change passwords for FTP users.

Login with an expired password

You can allow a user to log in a certain number of times within a period of time after the password expires. 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.

Password history

With this feature enabled, the system stores passwords that a user has used. When a user changes the password, the system compares the new password with the current password and those stored in the password history records. The new password must be different from the current one and those stored in the history records by a minimum of four characters. The four characters must be different from one another. Otherwise, the system will display an error message, and the password will not be changed.

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 most recent record overwrites the earliest one.

Current login passwords of device management users are not stored in the password history, because a device management user password is saved in cipher text and cannot be recovered to a plaintext password.

User login control

First login

If the global password control feature is enabled, users must change the password at first login before they can access the system. In this situation, password changes are not subject to the minimum password update interval.

Login attempt limit

Limiting the number of consecutive login failures can effectively prevent password guessing.

· Nonexistent users (users not configured on the device).

· Users logging in to the device through console ports.

If a user fails to log in, the system adds the user account and the user's IP address to the password control blacklist. When the user fails to log in after making the maximum number of consecutive attempts, login attempt limit limits the user and user account in any of the following ways:

· Disables the user account until the account is manually removed from the password control blacklist.

· Allows the user to continue using the user account. The user's IP address and user account are removed from the password control blacklist when the user uses this account to successfully log in to the device.

· Disables the user account for a period of time.

The user can use the account to log in when either of the following conditions exists:

? The locking timer expires.

? The account is manually removed from the password control blacklist before the locking timer expires.

NOTE:

This account is locked only for this user. Other users can still use this account, and the blacklisted user can use other user accounts.

Maximum account idle time

You can set the maximum account idle time for user accounts. When an account is idle for this period of time since the last successful login, the account becomes invalid.

Password not displayed in any form

For security purposes, nothing is displayed when a user enters a password.

Logging

The system logs all successful password changing events and user adding events to the password control blacklist.

Password control configuration task list

The password control features can be configured in several different views, and different views support different features. The settings configured in different views or for different objects have the following application ranges:

· Settings for super passwords apply only to super passwords.

· Settings in local user view apply only to the password of the local user.

· Settings in user group view apply to the passwords of the local users in the user group if you do not configure password policies for these users in local user view.

· Global settings in system view apply to the passwords of the local users in all user groups if you do not configure password policies for these users in both local user view and user group view.

For local user passwords, the settings with a smaller application scope have higher priority.

To configure password control, perform the following tasks:

Tasks 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

Enabling password control

To successfully enable the global password control feature and allow device management users to log in to the device, the device must have sufficient storage space.

Enabling the global password control feature is the prerequisite for all password control configurations to take effect. Then, for a specific password control feature to take effect, enable this password control feature.

After the global password control feature is enabled, you cannot display the password and super password configurations for device management users by using the corresponding display commands. However, the configuration for network access user passwords can be displayed. The first password configured for device management users must contain a minimum of four different characters.

To ensure correct function of password control, configure the device to use NTP to obtain the UTC time. After global password control is enabled, password control will record the UTC time when the password is set. The recorded UTC time might not be consistent with the actual UTC time due to power failure or device reboot. The inconsistency will cause the password expiration feature to malfunction. For information about NTP, see Network Management and Monitoring Configuration Guide.

To enable password control:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the global password control feature.	password-control enable	By default, the global password control feature is disabled.
3. (Optional.) Enable a specific password control feature.	password-control { aging \| composition \| history \| length } enable	By default, all four password control features are enabled.

Setting global password control parameters

The password expiration time, minimum password length, and password composition policy can be configured in system view, user group view, or local user view. The password settings with a smaller application scope have higher priority. Global settings in system view apply to the passwords of the local users in all user groups if you do not configure password policies for these users in both local user view and user group view.

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
1. Enter system view.	system-view	N/A
2. Set the password expiration time.	password-control aging aging-time	The default setting is 90 days.
3. Set the minimum password update interval.	password-control update interval interval	The default setting is 24 hours.
4. Set the minimum password length.	password-control length length	The default setting is 10 characters.
5. Configure the password composition policy.	password-control composition type-number type-number [ type-length type-length ]	By default, a password must contain a minimum of one character type and a minimum of one character for each type.
6. Configure the password complexity checking policy.	password-control complexity { same-character \| user-name } check	By default, the system does not perform password complexity checking.
7. Set the maximum number of history password records for each user.	password-control history max-record-number	The default setting is 4.
8. Configure the login attempt limit.	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.
9. Set the number of days during which a user is notified of the pending password expiration.	password-control alert-before-expire alert-time	The default setting is 7 days.
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	By default, a user can log in three times within 30 days after the password expires.
11. Set the maximum account idle time.	password-control login idle-time idle-time	The default setting is 90 days.

Setting user group password control parameters

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a user group and enter its view.	user-group group-name	By default, no user groups exist. For information about how to configure a user group, see "Configuring AAA."
3. Configure the password expiration time for the user group.	password-control aging aging-time	By default, the password expiration time of the user group equals the global password expiration time.
4. Configure the minimum password length for the user group.	password-control length length	By default, the minimum password length of the user group equals the global minimum password length.
5. Configure the password composition policy for the user group.	password-control composition type-number type-number [ type-length type-length ]	By default, the password composition policy of the user group equals the global password composition policy.
6. Configure the password complexity checking policy for the user group.	password-control complexity { same-character \| user-name } check	By default, the password complexity checking policy of the user group equals the global password complexity checking policy.
7. Configure the login attempt limit.	password-control login-attempt login-times [ exceed { lock \| lock-time time \| unlock } ]	By default, the login-attempt policy of the user group equals the global login-attempt policy.

Setting local user password control parameters

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a device management user and enter its view.	local-user user-name class manage	By default, no local users exist. Local user password control applies to device management users instead of network access users. For information about how to configure a local user, see "Configuring AAA."
3. Configure the password expiration 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 expiration time is configured for the user group, the global setting applies to the local user.
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.
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.
6. Configure the password complexity checking policy for the local user.	password-control complexity { same-character \| user-name } check	By default, the settings equal those for the user group to which the local user belongs. If no password complexity checking policy is configured for the user group, the global settings apply to the local user.
7. Configure the login attempt limit.	password-control login-attempt login-times [ exceed { lock \| lock-time time \| unlock } ]	By default, the settings equal those for the user group to which the local user belongs. If no login-attempt policy is configured for the user group, the global settings apply to the local user.

Setting super password control parameters

The super password allows you to obtain a temporary user role without reconnecting to the device. For more information, see Fundamentals Configuration Guide.

To set super password control parameters:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the password expiration time for super passwords.	password-control super aging aging-time	The default setting is 90 days.
3. Configure the minimum length for super passwords.	password-control super length length	The default setting is 10 characters.
4. Configure the password composition policy for super passwords.	password-control super composition type-number type-number [ type-length type-length ]	By default, a super password must contain a minimum of one character type and a minimum of one character for each type.

Displaying and maintaining password control

Execute display commands in any view and reset commands in user view.

Task	Command
Display password control configuration.	display password-control [ super ]
Display information about users in the password control blacklist.	display password-control blacklist [ user-name user-name \| ip ipv4-address \| ipv6 ipv6-address ]
Delete users from the password control blacklist.	reset password-control blacklist [ user-name user-name ]
Clear history password records.	reset password-control history-record [ user-name user-name \| super [ role role name ] ]

NOTE:

The reset password-control history-record command can delete the history password records of one or all users even when the password history feature is disabled.

Password control configuration example

Network requirements

Configure a global password control policy to meet the following requirements:

· A password must contain a minimum of 16 characters.

· A password must contain a minimum of four character types and a minimum of four characters for each type.

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

· A password expires after 30 days.

· The minimum password update interval is 36 hours.

· The maximum account idle time is 30 days.

· A password cannot contain the username or the reverse of the username.

· A minimum of three identical consecutive characters is not allowed in a password.

Configure a super password control policy for user role network-operator to meet the following requirements:

· A super password must contain a minimum of 24 characters.

· A super password must contain a minimum of four character types and a minimum of 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 a minimum of 24 characters.

· The password must contain a minimum of four character types and a minimum of five characters for each type.

· The password for the local user expires after 20 days.

Configuration procedure

# Enable the password control feature globally.

<Sysname> system-view

[Sysname] password-control enable

# Disable a user account permanently if a user fails two consecutive login attempts on the user account.

[Sysname] password-control login-attempt 2 exceed lock

# Set all passwords to expire after 30 days.

[Sysname] password-control aging 30

# Globally set the minimum password length to 16 characters.

[Sysname] password-control length 16

# Set the minimum password update interval to 36 hours.

[Sysname] password-control update-interval 36

# Specify that a user can log in five times within 60 days after the password expires.

[Sysname] password-control expired-user-login delay 60 times 5

# Set the maximum account idle time to 30 days.

[Sysname] password-control login idle-time 30

# Refuse any password that contains the username or the reverse of the username.

[Sysname] password-control complexity user-name check

# Refuse a password that contains a minimum of three identical consecutive characters.

[Sysname] password-control complexity same-character check

# Globally specify that all passwords must each contain a minimum of four character types and a minimum of four characters for each type.

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

# Set the minimum super password length to 24 characters.

[Sysname] password-control super length 24

# Specify that a super password must contain a minimum of four character types and a minimum of five characters for each type.

[Sysname] password-control super composition type-number 4 type-length 5

# Configure a super password used for switching to user role network-operator as 123456789ABGFTweuix@#$%! in plain text.

[Sysname] super password role network-operator simple 123456789ABGFTweuix@#$%!

# Create a device management user named test.

[Sysname] local-user test class manage

# Set the service type of the user to Telnet.

[Sysname-luser-manage-test] service-type telnet

# Set the minimum password length to 24 for the local user.

[Sysname-luser-manage-test] password-control length 24

# Specify that the password of the local user must contain a minimum of four character types and a minimum of five characters for each type.

[Sysname-luser-manage-test] password-control composition type-number 4 type-length 5

# Set the password for the local user to expire after 20 days.

[Sysname-luser-manage-test] password-control aging 20

# Configure the password of the local user in interactive mode.

[Sysname-luser-manage-test] password

Password:

Confirm :

Updating user information. Please wait ... ...

[Sysname-luser-manage-test] quit

Verifying the configuration

# Display the global password control configuration.

<Sysname> display password-control

Global password control configurations:

Password control: Enabled

Password aging: Enabled (30 days)

Password length: Enabled (16 characters)

Password composition: Enabled (4 types, 4 characters per type)

Password history: Enabled (max history record:4)

Early notice on password expiration: 7 days

Maximum login attempts: 2

Action for exceeding login attempts: Lock

Minimum interval between two updates: 36 hours

User account idle time: 30 days

Logins with aged password: 5 times in 60 days

Password complexity: Enabled (username checking)

Enabled (repeated characters checking)

# Display the password control configuration for super passwords.

<Sysname> display password-control super

Super password control configurations:

Password aging: Enabled (90 days)

Password length: Enabled (24 characters)

Password composition: Enabled (4 types, 5 characters per type)

# Display the password control configuration for local user test.

<Sysname> display local-user user-name test class manage

Total 1 local users matched.

Device management user test:

State: Active

Service type: Telnet

User group: system

Bind attributes:

Authorization attributes:

Work directory: flash:

User role list: network-operator

Password control configurations:

Password aging: 20 days

Password length: 24 characters

Password composition: 4 types, 5 characters per type

Managing public keys

Overview

This chapter describes public key management for the following asymmetric key algorithms:

· Revest-Shamir-Adleman Algorithm (RSA).

· Digital Signature Algorithm (DSA).

· Elliptic Curve Digital Signature Algorithm (ECDSA).

Many security applications, including SSH, SSL, and PKI, use asymmetric key algorithms to secure communications between two parties, as shown in Figure 80. Asymmetric key algorithms use two separate keys (one public and one private) for encryption and decryption. Symmetric key algorithms use only one key.

Figure 80 Encryption and decryption

A key owner can distribute the public key in plain text on the network but must keep the private key in privacy. It is mathematically infeasible to calculate the private key even if an attacker knows the algorithm and the public key.

The security applications use the asymmetric key algorithms for the following purposes:

· Encryption and decryption—Any public key receiver can use the public key to encrypt information, but only the private key owner can decrypt the information.

· Digital signature—The key owner uses the private key to digitally sign information to be sent. The receiver decrypts the information with the sender's public key to verify information authenticity.

RSA, DSA, and ECDSA can all perform digital signature, but only RSA can perform encryption and decryption.

Creating a local key pair

Restrictions and guidelines

When you create a local key pair, follow these guidelines:

· The key algorithm must be the same as required by the security application.

· When you create an RSA or DSA key pair, enter an appropriate key modulus length at the prompt. The longer the key modulus length, the higher the security, and the longer the key generation time.

When you create an ECDSA key pair, choose the appropriate elliptic curve. The elliptic curve determines the ECDSA key length. The longer the key length, the higher the security, and the longer the key generation time.

See Table 8 for more information about key modulus lengths and key lengths.

· If you do not assign the key pair a name, the system assigns the default name to the key pair and marks the key pair as default. You can also assign the default name to another key pair, but the system does not mark the key pair as default. The key pair name must be unique among all manually named key pairs that use the same key algorithm. If a name conflict occurs, the system asks whether you want to overwrite the existing key pair.

· The key pairs are automatically saved and can survive system reboots.

Table 8 A comparison of different types of asymmetric key algorithms

Type	Number of key pairs	Modulus/key length
RSA	· One host key pair, if you specify a key pair name. · One server key pair and one host key pair, if you do not specify a key pair name. Both key pairs use their default names. NOTE: Only SSH 1.5 uses the RSA server key pair.	RSA key modulus length: 512 to 2048 bits, 1024 bits by default. To ensure security, use a minimum of 768 bits.
DSA	One host key pair.	DSA key modulus length: 512 to 2048 bits, 1024 bits by default. To ensure security, use a minimum of 768 bits.
ECDSA	One host key pair.	ECDSA key length: 192, 256, or 384 bits.

Procedure

To create a local key pair:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a local key pair.	public-key local create { dsa \| ecdsa [ secp192r1 \| secp256r1 \| secp384r1 ] \| rsa } [ name key-name ]	By default, no local key pairs exist.

Distributing a local host public key

You must distribute a local host public key to a peer device so the peer device can perform the following operations:

· Use the public key to encrypt information sent to the local device.

· Authenticate the digital signature signed by the local device.

To distribute a local host public key, you must first export or display the key.

· Export a host public key:

? Export a host public to a file.

? Export a host public key to the monitor screen, and then save it to a file.

After the key is exported to a file, transfer the file to the peer device. On the peer device, import the key from the file.

· Display a host public key.

After the key is displayed, record the key, for example, copy it to an unformatted file. On the peer device, you must literally enter the key.

Exporting a host public key

When you export a host public key, follow these restrictions and guidelines:

· If you specify a file name in the command, the command exports the key to the specified file.

· If you do not specify a file name, the command exports the key to the monitor screen. You must manually save the exported key to a file.

To export a local host public key:

Step

Command

1. Enter system view.

system-view

2. Export a local host public key.

· Export an RSA host public key:
public-key local export rsa [ name key-name ] { openssh | ssh1 | ssh2 } [ filename ]

· Export an ECDSA host public key:
public-key local export ecdsa [ name key-name ] { openssh | ssh2 } [ filename ]

· Export a DSA host public key:
public-key local export dsa [ name key-name ] { openssh | ssh2 } [ filename ]

Displaying a host public key

Perform the following tasks in any view:

Task	Command
Display local RSA public keys.	display public-key local rsa public [ name key-name ]
Display local ECDSA public keys.	display public-key local ecdsa public [ name key-name ]
Display local DSA public keys.	display public-key local dsa public [ name key-name ]

NOTE:

Do not distribute the RSA server public key serverkey (default) to a peer device.

Destroying a local key pair

To avoid key compromise, destroy the local key pair and generate a new pair after any of the following conditions occurs:

· An intrusion event has occurred.

· The storage media of the device is replaced.

· The local certificate has expired. For more information about local certificates, see "Configuring PKI."

To destroy a local key pair:

Step	Command
1. Enter system view.	system-view
2. Destroy a local key pair.	public-key local destroy { dsa \| ecdsa \| rsa } [ name key-name ]

Configuring a peer host public key

To encrypt information sent to a peer device or authenticate the digital signature of the peer device, you must configure the peer device's public key on the local device.

You can configure the peer host public key by using the following methods:

· Import the peer host public key form a public key file (recommended).

· Manually enter (type or copy) the peer host public key.

Importing a peer host public key from a public key file

Before you perform this task, make sure you have exported the host public key to a file on the peer device and obtained the file from the peer device. For information about exporting a host public key, see "Exporting a host public key."

After you import the key, the system automatically converts the imported public key to a string in the Public Key Cryptography Standards (PKCS) format.

To import a peer host public key from a public key file:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Import a peer host public key from a public key file.	public-key peer keyname import sshkey filename	By default, no peer host public keys exist.

Entering a peer host public key

Before you perform this task, make sure you have displayed the key on the peer device and recorded the key. For information about displaying a host public key, see "Displaying a host public key."

Use the display public-key local public command to display the public key on the peer device. The format of the public key displayed in any other way might be incorrect. If the key is not in the correct format, the system discards the key and displays an error message. If the key is valid, the system saves the key.

Always import rather than enter the peer host public key if you are not sure that the device supports the format of the recorded peer host public key.

To enter a peer host public key:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Specify a name for the peer host public key and enter public key view.	public-key peer keyname	By default, no peer host public keys exist.
3. Type or copy the key.	N/A	You can use spaces and carriage returns, but the system does not save them.
4. Return to system view.	peer-public-key end	When you exit public key view, the system automatically saves the peer host public key.

Displaying and maintaining public keys

Execute display commands in any view.

Task	Command
Display local public keys.	display public-key local { dsa \| ecdsa \| rsa } public [ name key-name ]
Display peer host public keys.	display public-key peer [ brief \| name publickey-name ]

Examples of public key management

Example for entering a peer host public key

Network requirements

As shown in Figure 81, to prevent illegal access, the AC authenticates the device through a digital signature. Before configuring authentication parameters on the AC, 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 on the AC.

Figure 81 Network diagram

Configuration procedure

1. Configure the device:

# Create local RSA key pairs with default names on the device, and use the default modulus length 1024 bits.

<Device> system-view

[Device] public-key local create rsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

.................++++++

......................................++++++

.....++++++++

..............++++++++

Create the key pair successfully.

# Display all local RSA public keys.

[Device] display public-key local rsa public

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

Key name: hostkey (default)

Key type: RSA

Time when key pair created: 16:48:31 2015/05/12

Key code:

30819F300D06092A864886F70D010101050003818D0030818902818100DA3B90F59237347B

8D41B58F8143512880139EC9111BFD31EB84B6B7C7A1470027AC8F04A827B30C2CAF79242E

45FDFF51A9C7E917DB818D54CB7AEF538AB261557524A7441D288EC54A5D31EFAE4F681257

6D7796490AF87A8C78F4A7E31F0793D8BA06FB95D54EBB9F94EB1F2D561BF66EA27DFD4788

CB47440AF6BB25ACA50203010001

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

Key name: serverkey (default)

Key type: RSA

Time when key pair created: 16:48:31 2015/05/12

Key code:

307C300D06092A864886F70D0101010500036B003068026100C9451A80F7F0A9BA1A90C7BC

1C02522D194A2B19F19A75D9EF02219068BD7FD90FCC2AF3634EEB9FA060478DD0A1A49ACE

E1362A4371549ECD85BA04DEE4D6BB8BE53B6AED7F1401EE88733CA3C4CED391BAE633028A

AC41C80A15953FB22AA30203010001

2. Configure the AC:

# Enter the host public key of the device in public key view. The key must be literally the same as displayed on the device.

<AC> system-view

[AC] public-key peer device

Enter public key view. Return to system view with "peer-public-key end" command.

[AC-pkey-public-key-device]30819F300D06092A864886F70D010101050003818D003081890

2818100DA3B90F59237347B

[AC-pkey-public-key-device]8D41B58F8143512880139EC9111BFD31EB84B6B7C7A1470027A

C8F04A827B30C2CAF79242E

[AC-pkey-public-key-device]45FDFF51A9C7E917DB818D54CB7AEF538AB261557524A7441D2

88EC54A5D31EFAE4F681257

[AC-pkey-public-key-device]6D7796490AF87A8C78F4A7E31F0793D8BA06FB95D54EBB9F94E

B1F2D561BF66EA27DFD4788

[AC-pkey-public-key-device]CB47440AF6BB25ACA50203010001

# Save the public key and return to system view.

[AC-pkey-public-key-device] peer-public-key end

Verifying the configuration

# Verify that the peer host public key configured on the AC is the same as the key displayed on the device.

[AC] display public-key peer name device

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

Key name: device

Key type: RSA

Key modulus: 1024

Key code:

30819F300D06092A864886F70D010101050003818D0030818902818100DA3B90F59237347B

8D41B58F8143512880139EC9111BFD31EB84B6B7C7A1470027AC8F04A827B30C2CAF79242E

45FDFF51A9C7E917DB818D54CB7AEF538AB261557524A7441D288EC54A5D31EFAE4F681257

6D7796490AF87A8C78F4A7E31F0793D8BA06FB95D54EBB9F94EB1F2D561BF66EA27DFD4788

CB47440AF6BB25ACA50203010001

Example for importing a public key from a public key file

Network requirements

As shown in Figure 82, the AC authenticates the device through a digital signature. Before configuring authentication parameters on the AC, 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.

· Import the host public key of the device from the public key file to the AC.

Figure 82 Network diagram

Configuration procedure

1. Configure the device:

# Create local RSA key pairs with default names on the device, and use the default modulus length 1024 bits.

<Device> system-view

[Device] public-key local create rsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

.................++++++

......................................++++++

.....++++++++

..............++++++++

Create the key pair successfully.

# Display all local RSA public keys.

[Device] display public-key local rsa public

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

Key name: hostkey (default)

Key type: RSA

Time when key pair created: 16:48:31 2015/05/12

Key code:

30819F300D06092A864886F70D010101050003818D0030818902818100DA3B90F59237347B

8D41B58F8143512880139EC9111BFD31EB84B6B7C7A1470027AC8F04A827B30C2CAF79242E

45FDFF51A9C7E917DB818D54CB7AEF538AB261557524A7441D288EC54A5D31EFAE4F681257

6D7796490AF87A8C78F4A7E31F0793D8BA06FB95D54EBB9F94EB1F2D561BF66EA27DFD4788

CB47440AF6BB25ACA50203010001

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

Key name: serverkey (default)

Key type: RSA

Time when key pair created: 16:48:31 2015/05/12

Key code:

307C300D06092A864886F70D0101010500036B003068026100C9451A80F7F0A9BA1A90C7BC

1C02522D194A2B19F19A75D9EF02219068BD7FD90FCC2AF3634EEB9FA060478DD0A1A49ACE

E1362A4371549ECD85BA04DEE4D6BB8BE53B6AED7F1401EE88733CA3C4CED391BAE633028A

AC41C80A15953FB22AA30203010001

# Export the RSA host public key to the file device.pub.

[Device] public-key local export rsa ssh2 device.pub

[Device] quit

# Enable the FTP server function, create an FTP user with the username ftp and password 123, and configure the FTP user role as network-admin.

[Device] ftp server enable

[Device] local-user ftp

[Device-luser-manage-ftp] password simple 123

[Device-luser-manage-ftp] service-type ftp

[Device-luser-manage-ftp] authorization-attribute user-role network-admin

[Device-luser-manage-ftp] quit

2. Configure the AC:

# Use FTP in binary mode to get the public key file device.pub from the device.

<AC> ftp 10.1.1.1

Connected to 10.1.1.1 (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.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> binary

200 TYPE is now 8-bit binary

ftp> get device.pub

227 Entering Passive Mode (10,1,1,1,118,252)

150 Accepted data connection

226 File successfully transferred

301 bytes received in 0.003 seconds (98.0 kbyte/s)

ftp> quit

221-Goodbye. You uploaded 0 and downloaded 1 kbytes.

221 Logout.

# Import the host public key from the key file device.pub.

<AC> system-view

[AC] public-key peer device import sshkey device.pub

Verifying the configuration

# Verify that the peer host public key configured on the AC is the same as the key displayed on the device.

[AC] display public-key peer name device

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

Key name: device

Key type: RSA

Key modulus: 1024

Key code:

30819F300D06092A864886F70D010101050003818D0030818902818100DA3B90F59237347B

8D41B58F8143512880139EC9111BFD31EB84B6B7C7A1470027AC8F04A827B30C2CAF79242E

45FDFF51A9C7E917DB818D54CB7AEF538AB261557524A7441D288EC54A5D31EFAE4F681257

6D7796490AF87A8C78F4A7E31F0793D8BA06FB95D54EBB9F94EB1F2D561BF66EA27DFD4788

CB47440AF6BB25ACA50203010001

Configuring PKI

Overview

Public Key Infrastructure (PKI) is an asymmetric key infrastructure to encrypt and decrypt data for securing network services. Data encrypted with the public key can be decrypted only with the private key. Likewise, data encrypted with the private key can be decrypted only with the public key.

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.

H3C's PKI system provides certificate management for IPsec and SSL.

PKI terminology

Digital certificate

A digital certificate is an electronic document signed by a CA that binds a public key with the identity of its owner.

A digital certificate includes the following information:

· Issuer name (name of the CA that issued the certificate).

· Subject name (name of the individual or group to which the certificate is issued).

· Identity information of the subject.

· Subject's public key.

· Signature of the CA.

· Validity period.

A digital certificate must comply with the international standards of ITU-T X.509, of which X.509 v3 is the most commonly used.

This chapter covers the following types of certificates:

· CA certificate—Certificate of a CA. Multiple CAs in a PKI system form a CA tree, with the root CA at the top. The root CA generates a self-signed certificate, and each lower level CA holds a CA certificate issued by the CA immediately above it. The chain of these certificates forms a chain of trust.

· Registration authority (RA) certificate—Certificate issued by a CA to an RA. RAs act as proxies for CAs to process enrollment requests in a PKI system.

· Local certificate—Digital certificate issued by a CA to a local PKI entity, which contains the entity's public key.

· Peer certificate—CA-signed digital certificate of a peer, which contains the peer's public key.

Certificate revocation list

A certificate revocation list (CRL) is a list of serial numbers for certificates that have been revoked. A CRL is created and signed by the CA that originally issued the certificates.

The CA publishes CRLs periodically to revoke certificates. Entities that are associated with the revoked certificates should not be trusted.

The CA must revoke a certificate when any of the following conditions occurs:

· The certificate subject name is changed.

· The private key is compromised.

· The association between the subject and CA is changed. For example, when an employee terminates employment with an organization.

CA policy

A CA policy is a set of criteria that a CA follows to process certificate requests, to issue and revoke certificates, and to publish CRLs. Typically, a CA advertises its policy in a certification practice statement (CPS). You can obtain a CA policy through out-of-band means such as phone, disk, and email. Make sure you understand the CA policy before you select a trusted CA for certificate request because different CAs might use different policies.

PKI architecture

A PKI system consists of PKI entities, CAs, RAs and a certificate/CRL repository, as shown in Figure 83.

Figure 83 PKI architecture

· PKI entity—An end user using PKI certificates. The PKI entity can be an operator, an organization, a device like a router or a switch, or a process running on a computer. PKI entities use SCEP to communicate with the CA or RA.

· CA—Certification authority that grants and manages certificates. A CA issues certificates, defines the certificate validity periods, and revokes certificates by publishing CRLs.

· RA—Registration authority, which offloads the CA by processing enrollment requests. The RA accepts certificate requests, verifies user identity, and determines whether to ask the CA to issue certificates.

The RA is optional in a PKI system. In cases when the CA operates over a wide geographical area or when there is security concern over exposing the CA to direct network access, it is advisable to delegate some of the tasks to an RA and leave the CA to concentrate on its primary tasks of signing certificates and CRLs.

· Certificate/CRL repository—A certificate distribution point that stores certificates and CRLs, and distributes these certificates and CRLs to PKI entities. It also provides the query function. A PKI repository can be a directory server using the LDAP or HTTP protocol, of which LDAP is commonly used.

PKI operation

The following workflow describes how a PKI entity requests a local certificate from a CA that has RAs:

1. A PKI entity submits a certificate request to the RA.

2. The RA verifies the identity of the entity and sends a digital signature containing the identity information and the public key to the CA.

3. The CA verifies the digital signature, approves the request, and issues a certificate.

4. After receiving the certificate from the CA, the RA sends the certificate to the certificate repositories and notifies the PKI entity that the certificate has been issued.

5. The entity obtains the certificate from the certificate repository.

PKI applications

The PKI technology can meet security requirements of online transactions. As an infrastructure, PKI has a wide range of applications. Here are some application examples.

· VPN—A VPN is a private data communication network built on the public communication infrastructure. A VPN can use network layer security protocols (for example, IPsec) in conjunction with PKI-based encryption and digital signature technologies for confidentiality.

· Secure emails—PKI can address the email requirements for confidentiality, integrity, authentication, and non-repudiation. A common secure email protocol is Secure/Multipurpose Internet Mail Extensions (S/MIME), which is based on PKI and allows for transfer of encrypted mails with signature.

· Web security—PKI can be used in the SSL handshake phase to verify the identities of the communicating parties by digital certificates.

PKI configuration task list

Tasks at a glance
(Required.) Configuring a PKI entity
(Required.) Configuring a PKI domain
(Required.) Requesting a certificate: · Configuring automatic certificate request · Manually requesting a certificate

(Optional.) Aborting a certificate request
(Optional.) Obtaining certificates
(Optional.) Verifying PKI certificates
(Optional.) Specifying the storage path for the certificates and CRLs
(Optional.) Exporting certificates
(Optional.) Removing a certificate
(Optional.) Configuring a certificate-based access control policy

Configuring a PKI entity

A certificate applicant uses an entity to provide its identity information to a CA. A valid PKI entity must include one or more of following identity categories:

· Distinguished name (DN) of the entity, which further includes the common name, county code, locality, organization, unit in the organization, and state. If you configure the DN for an entity, a common name is required.

· FQDN of the entity.

· IP address of the entity.

Whether the categories are required or optional depends on the CA policy. Follow the CA policy to configure the entity settings. For example, if the CA policy requires the entity DN, but you configure only the IP address, the CA rejects the certificate request from the entity.

The SCEP add-on on the Windows 2000 CA server has restrictions on the data length of a certificate request. If a request from a PKI entity exceeds the data length limit, the CA server does not respond to the certificate request. In this case, you can use an out-of-band means to submit the request. Other types of CA servers, such as RSA servers and OpenCA servers, do not have such restrictions.

To configure a PKI entity:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a PKI entity and enter its view.	pki entity entity-name	By default, no PKI entities exist. To create multiple PKI entities, repeat this step.
3. Configure the DN for the PKI entity.	· Configure individual DN attributes to construct the subject DN string: ? Set the common name attribute: common-name common-name-sting ? Set the country code attribute: country country-code-string ? Set the locality attribute: locality locality-name ? Set the organization attribute: organization org-name ? Set the organization unit attribute: organization-unit org-unit-name ? Set the state attribute: state state-name · Configure the full subject DN string: subject-dn dn-string	By default, no DN attributes are configured for a PKI entity. If the subject-dn command is configured, the common-name, country, locality, organization, organization-unit, and state commands do not take effect.
4. Set the FQDN of the entity.	fqdn fqdn-name-string	By default, the FQDN is not set.
5. Configure the IP address of the entity.	ip { ip-address \| interface interface-type interface-number }	By default, the IP address is not configured.

Configuring a PKI domain

A PKI domain contains enrollment information for a PKI entity. It is locally significant and is intended only for reference by other applications like IKE and SSL.

To configure a PKI domain:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a PKI domain and enter its view.	pki domain domain-name	By default, no PKI domains exist.
3. Specify the trusted CA.	ca identifier name	By default, no trusted CA is specified. To obtain a CA certificate, the trusted CA name must be provided. The trusted CA name uniquely identifies the CA to be used if multiple CAs exist on the same CA server. The CA server's URL is specified by using the certificate request url command.
4. Specify the PKI entity name.	certificate request entity entity-name	By default, no entity is specified.
5. Specify the type of certificate request reception authority.	certificate request from { ca \| ra }	By default, no authority type is specified.
6. Specify the certificate request URL.	certificate request url url-string	By default, the certificate request URL is not specified.
7. (Optional.) Set the SCEP polling interval and maximum number of polling attempts.	certificate request polling { count count \| interval interval }	By default, the device polls the CA server for the certificate request status every 20 minutes. The maximum number of polling attempts is 50.
8. (Optional.) Specify the LDAP server.	ldap-server host hostname [ port port-number ]	This task is required only when the CRL repository is an LDAP server and the URL of the CRL repository does not contain the host name of the LDAP server. By default, no LDAP server is specified.
9. Enter a fingerprint to be matched against the fingerprint of the root CA certificate.	root-certificate fingerprint { md5 \| sha1 } string	Before a PKI entity can enroll with a CA, it must authenticate the CA by obtaining the self-signed certificate of the CA and verifying the fingerprint of the CA certificate. If a fingerprint is not entered in the PKI domain, and if the CA certificate is imported or obtained through manual certificate request, you must verify the fingerprint that is displayed during authentication of the CA certificate. If the CA certificate is obtained through automatic certificate request, the certificate will be rejected if a fingerprint has not been entered. By default, no fingerprint is specified.
10. Specify the key pair for certificate request.	· Specify an RSA key pair: public-key rsa { { encryption name encryption-key-name [ length key-length ] \| signature name signature-key-name [ length key-length ] } * \| general name key-name [ length key-length ] } · Specify an ECDSA key pair: public-key ecdsa name key-name · Specify a DSA key pair: public-key dsa name key-name [ length key-length ]	By default, no key pair is specified. If the specified key pair does not exist, the PKI entity automatically creates the key pair before submitting a certificate request. For information about how to generate DSA, ECDSA, and RSA key pairs, see "Managing public keys."
11. (Optional.) Specify the intended use for the certificate.	usage { ike \| ssl-client \| ssl-server } *	By default, the certificate can be used by all applications, including IKE, SSL clients, and SSL server. The extension options contained in an issued certificate depend on the CA policy, and they might be different from those specified in the PKI domain.
12. Specify a source IP address for the PKI protocol packets.	· Specify the source IPv4 address for the PKI protocol packets: source ip { ip-address \| interface {interface-type interface-number } · Specify the source IPv6 address for the PKI protocol packets: source ipv6 { ipv6-address \| interface { interface-type interface-number }}	This task is required if the CA policy requires that the CA server accept certificate requests from a specific IP address or subnet. By default, the source IP address of PKI protocol packets is the IP address of their outgoing interface.

Requesting a certificate

To request a certificate, a PKI entity must provide its identity information and public key to a CA.

A certificate request can be submitted to a CA in offline or online mode.

· Offline mode—A certificate request is submitted by using an out-of-band method, such as phone, disk, or email. You can use this mode as required or if you fail to request a certificate in online mode.

To submit a certificate request in offline mode:

a. Use pki request-certificate domain pkcs10 to print the request information on the terminal or use pki request-certificate domain pkcs10 filename to save the request information to a local file.

b. Send the printed information or the saved file to the CA by using an out-of-band method.

· Online mode—A certificate request can be automatically or manually submitted. This section describes the online request mode.

Configuration guidelines

The following guidelines apply to certificate request for an entity in a PKI domain:

· Make sure the device is time synchronized with the CA server. Otherwise, the certificate request might fail because the certificate might be considered to be outside of the validity period. For information about how to configure the system time, see Fundamentals Configuration Guide.

· To request a new certificate for a PKI entity that already has a local certificate, perform the following tasks:

a. Use the pki delete-certificate command to delete the existing local certificate.

b. Use the public-key local create to generate a new key pair. The new key pair will automatically overwrite the old key pair in the domain.

c. Submit a new certificate request.

· After a new certificate is obtained, do not use the public-key local create or public-key local destroy command to generate or destroy a key pair with the same name as the key pair in the local certificate. Otherwise, the existing local certificate becomes unavailable.

· A PKI domain can have local certificates using only one type of cryptographic algorithms (DSA, ECDSA, or RSA). If DSA or ECDSA is used, a PKI domain can have only one local certificate. If RSA is used, a PKI domain can have one local certificate for signature, and one local certificate for encryption.

Configuring automatic certificate request

In auto request mode, a PKI entity with no local certificates automatically submits a certificate request to the CA when an application works with the PKI entity. For example, when IKE negotiation uses a digital signature for identity authentication, but no local certificate is available, the entity automatically submits a certificate request. It saves the certificate locally after obtaining the certificate from the CA.

A CA certificate must be present before you request a local certificate. If no CA certificate exists in the PKI domain, the PKI entity automatically obtains a CA certificate before sending a certificate request.

Configuration restrictions and guidelines

Follow these restrictions and guidelines when you configure automatic certificate request:

· To avoid service interruptions caused by certificate expiration, specify the renew-before-expire days option to enable certificate auto-renewal in auto certificate request mode.

Certificate auto-renewal enables the system to automatically request a new certificate the specified number of days before the old certificate expires. The old certificate is replaced immediately when the new certificate is received.

· Some CAs require a new PKI entity common name for certificate auto-renewal to work. Specify the automatic-append common-name keyword to ensure successful certificate auto-renewal.

Configuration procedure

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 [ password { cipher \| simple } string \| renew-before-expire days [ reuse-public-key ] [ automatic-append common-name ] ] *	By default, the manual request mode applies. In auto request mode, set a password for certificate revocation as required by the CA policy.

Manually requesting a certificate

Before you manually submit a certificate request, make sure the CA certificate exists and a key pair is specified for the PKI domain:

· The CA certificate is used to verify the authenticity and validity of the obtained local certificate.

· The key pair is used for certificate request. Upon receiving the public key and the identity information, the CA signs and issues a certificate.

After the CA issues the certificate, the device obtains and saves it locally.

To manually request a certificate:

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	By default, the manual request mode applies.
4. Return to system view.	quit	N/A
5. Obtain a CA certificate.	See "Obtaining certificates."	N/A
6. Submit a certificate request or generate a certificate request in PKCS#10 format.	pki request-certificate domain domain-name [ password password ] [ pkcs10 [ filename filename ] ]	This command is not saved in the configuration file. This command triggers the PKI entity to automatically generate a key pair if the key pair specified in the PKI domain does not exist. The name, algorithm, and length of the key pair are configured in the PKI domain.

Aborting a certificate request

Before the CA issues a certificate, you can abort a certificate request and change its parameters, such as the common name, country code, or FQDN. You can use the display pki certificate request-status command to display the status of a certificate request.

Alternatively, you also can remove a PKI domain to abort the associated certificate request.

To abort a certificate request:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Abort a certificate request.	pki abort-certificate-request domain domain-name	This command is not saved in the configuration file.

Obtaining certificates

You can obtain the CA certificate, local certificates, and peer certificates related to a PKI domain from a CA and save them locally for higher lookup efficiency. To do so, use either the offline mode or the online mode:

· In offline mode, obtain the certificates by an out-of-band means like FTP, disk, or email, and then import them locally. Use this mode when the CRL repository is not specified, the CA server does not support SCEP, or the CA server generates the key pair for the certificates.

· In online mode, you can obtain the CA certificate through SCEP and obtain local certificates or peer certificates through LDAP.

Configuration prerequisites

To obtain local or peer certificates in online mode, specify the LDAP server for the PKI domain.

To import local or peer certificates in offline mode, perform the following tasks:

· Use FTP or TFTP to upload the certificate files to the storage media of the device. If FTP or TFTP is not available, display and copy the contents of a certificate to a file on the device. Make sure the certificate is in PEM format because only certificates in PEM format can be imported.

· To import a certificate, a CA certificate chain must exist in the PKI domain, or be contained in the certificate. If the CA certificate chain is not available, obtain it before importing the certificate.

Configuration guidelines

· To import a local certificate containing an encrypted key pair, you must provide the challenge password. Contact the CA administrator to obtain the password.

· If a CA certificate already exists locally, you cannot obtain it again in online mode. If you want to obtain a new one, use the pki delete-certificate command to remove the existing CA certificate and local certificates first.

· If local or peer certificates already exist, you can obtain new local or peer certificates to overwrite the existing ones. If RSA is used, a PKI domain can have two local certificates, one for signature and the other for encryption.

· If CRL checking is enabled, obtaining a certificate triggers CRL checking. If the certificate to be obtained has been revoked, the certificate cannot be obtained.

· The device compares the validity period of a certificate with the local system time to determine whether the certificate is valid. Make sure the system time of the device is synchronized with the CA server.

Configuration procedure

To obtain certificates:

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Obtain certificates.

· Import certificates in offline mode:
pki import domain domain-name { der { ca | local | peer } filename filename | p12 local filename filename | pem { ca | local | peer } [ filename filename ] }

· Obtain certificates in online mode:
pki retrieve-certificate domain domain-name { ca | local | peer entity-name }

The pki retrieve-certificate command is not saved in the configuration file.

Verifying PKI certificates

A certificate is automatically verified when it is requested, obtained, or used by an application. If the certificate expires, if it is not issued by a trusted CA, or if it is revoked, the certificate cannot be used.

You can also manually verify a certificate. If it has been revoked, the certificate cannot be requested or obtained.

Verifying certificates with CRL checking

CRL checking checks whether a certificate is in the CRL. If it is, the certificate has been revoked and its home entity is not trusted.

To use CRL checking, a CRL must be obtained from a CRL repository. The device selects a CRL repository in the following order:

1. CRL repository specified in the PKI domain by using this command.

2. CRL repository in the certificate that is being verified.

3. CRL repository in the CA certificate or CRL repository in the upper-level CA certificate if the CA certificate is the certificate being verified.

If no CRL repository is found after the selection process, the device obtains the CRL through SCEP. In this scenario, the CA certificate and the local certificates must have been obtained.

When verifying the CA certificate of a PKI domain, the system needs to verify all the certificates in the CA certificate chain of the domain. To ensure a successful certificate verification process, the device must contain all the PKI domains to which the CA certificates in the certificate chain belong.

Each CA certificate contains an issuer field that identifies the parent CA that issued the certificate. After identifying the parent certificate of a certificate, the system locates the PKI domains to which the parent certificate belongs. If CRL checking is enabled for the domains, the system checks whether or not the CA certificate has been revoked. The process continues until the root CA certificate is reached. The system verifies that each CA certificate in the certificate chain is issued by the named parent CA, starting from the root CA.

To verify 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
3. (Optional.) Specify the URL of the CRL repository.	crl url url-string	By default, the URL of the CRL repository is not specified.
4. Enable CRL checking.	crl check enable	By default, CRL checking is enabled.
5. Return to system view.	quit	N/A
6. Obtain the CA certificate.	See "Obtaining certificates."	N/A
7. (Optional.) Obtain the CRL and save it locally.	pki retrieve-crl domain domain-name	The newly obtained CRL overwrites the old one, if any. The obtained CRL must be issued by a CA certificate in the CA certificate chain in the current domain.
8. Manually verify the validity of the certificates.	pki validate-certificate domain domain-name { ca \| local }	N/A

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.	undo crl check enable	By default, CRL checking is enabled.
4. Return to system view.	quit	N/A
5. Obtain the CA certificate.	See "Obtaining certificates."	N/A
6. Manually verify the validity of the certificates.	pki validate-certificate domain domain-name { ca \| local }	This command is not saved in the configuration file.

Specifying the storage path for the certificates and CRLs

CAUTION:

If you change the storage path, save the configuration before you reboot or shut down the device to avoid loss of the certificates or the CRLs.

The device has a default storage path for certificates and CRLs. You can change the storage path and specify different paths for the certificates and CRLs.

After you change the storage path for certificates or CRLs, the certificate files (with the .cer or .p12 extension) and CRL files (with the .crl extension) in the original path are moved to the new path.

To specify the storage path for certificates and CRLs:

Task	Command	Remarks
Specify the storage path for certificates and CRLs.	pki storage { certificates \| crls } dir-path	By default, the device stores certificates and CRLs in the PKI directory on the storage media of the device.

Exporting certificates

IMPORTANT:

To export all certificates in the PKCS12 format, the PKI domain must have a minimum of one local certificate. Otherwise, the certificates in the PKI domain cannot be exported.

You can export the CA certificate and the local certificates in a PKI domain to certificate files. The exported certificate files can then be imported back to the device or other PKI applications.

When you export a local certificate with the RSA key pair, the name of the target file might be different than the file name specified with the filename keyword. It depends on the purpose of the key pair of the certificate.

To export certificates:

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Export certificates.

· Export certificates in DER format:
pki export domain domain-name der { all | ca | local } filename filename

· Export certificates in PKCS12 format:
pki export domain domain-name p12 { all | local } passphrase p12-key filename filename

· Export certificates in PEM format:
pki export domain domain-name pem { { all | local } [ { 3des-cbc | aes-128-cbc | aes-192-cbc | aes-256-cbc | des-cbc } pem-key ] | ca } [ filename filename ]

If you do not specify a file name when you export a certificate in PEM format, the certificate is displayed on the terminal.

Removing a certificate

You can remove the CA certificate, local certificate, or peer certificates in a PKI domain. After you remove the CA certificate, the system automatically removes the local certificates, peer certificates, and CRLs in the domain.

You can remove a local certificate and request a new one when the local certificate is about to expire or the certificate's private key is compromised. To remove a local certificate and request a new certificate, perform the following tasks:

1. Remove the local certificate.

2. Use the public-key local destroy command to destroy the existing local key pair.

3. Use the public-key local create command to generate a new key pair.

4. Request a new certificate.

To remove a certificate:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Remove a certificate.	pki delete-certificate domain domain-name { ca \| local \| peer [ serial serial-num ] }	If you use the peer keyword without specifying a serial number, this command removes all peer certificates.

Configuring a certificate-based access control policy

Certificate-based access control policies allow you to authorize access to a device (for example, an HTTPS server) based on the attributes of an authenticated client's certificate.

A certificate-based access control policy is a set of access control rules (permit or deny statements), each associated with a certificate attribute group. A certificate attribute group contains multiple attribute rules, each defining a matching criterion for an attribute in the certificate issuer name, subject name, or alternative subject name field.

If a certificate matches all attribute rules in a certificate attribute group associated with an access control rule, the system determines that the certificate matches the access control rule. In this scenario, the match process stops, and the system performs the access control action defined in the access control rule.

The following conditions describe how a certificate-based access control policy verifies the validity of a certificate:

· If a certificate matches a permit statement, the certificate passes the verification.

· If a certificate matches a deny statement or does not match any statements in the policy, the certificate is regarded invalid.

· If a statement is associated with a non-existing attribute group, or the attribute group does not have attribute rules, the certificate matches the statement.

· If the certificate-based access control policy referenced by a security application (for example, HTTPS) does not exist, all certificates in the application pass the verification.

To configure a certificate-based 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	By default, no certificate attribute groups exist.
3. (Optional.) Configure an attribute rule for issuer name, 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	By default, not attribute rules are configured.
4. Return to system view.	quit	N/A
5. Create a certificate-based access control policy and enter its view.	pki certificate access-control-policy policy-name	By default, no certificate-based access control policy exists.
6. Create a certificate access control rule.	rule [ id ] { deny \| permit } group-name	By default, no certificate access control rules are configured, and all certificates can pass the verification. You can create multiple certificate access control rules for a certificate-based access control policy.

Displaying and maintaining PKI

Execute display commands in any view.

Task	Command
Display the contents of a certificate.	display pki certificate domain domain-name { ca \| local \| peer [ serial serial-num ] }
Display the certificate renewal status.	display pki certificate renew-status [ domain domain-name ]
Display certificate request status.	display pki certificate request-status [ domain domain-name ]
Display locally stored CRLs in a PKI domain.	display pki crl domain domain-name
Display certificate attribute group information.	display pki certificate attribute-group [ group-name ]
Display certificate-based access control policy information.	display pki certificate access-control-policy [ policy-name ]

PKI configuration examples

You can use different software applications, such as Windows server, RSA Keon, and OpenCA, to act as the CA server.

If you use Windows server or OpenCA, you must install the SCEP add-on for Windows server or enable SCEP for OpenCA. In either case, when you configure a PKI domain, you must use the certificate request from ra command to specify the RA to accept certificate requests.

If you use RSA Keon, the SCEP add-on is not required. When you configure a PKI domain, you must use the certificate request from ca command to specify the CA to accept certificate requests.

Requesting a certificate from an RSA Keon CA server

Network requirements

Configure the PKI entity (the AC) to request a local certificate from the CA server.

Figure 84 Network diagram

Configuring the RSA Keon CA server

1. Create a CA server named myca:

In this example, you must configure these basic attributes on the CA server:

? Nickname—Name of the trusted CA.

? Subject DN—DN attributes of the CA, including the common name (CN), organization unit (OU), organization (O), and country (C).

You can use the default values for other attributes.

2. Configure extended attributes:

Configure parameters in the Jurisdiction Configuration section on the management page of the CA server:

? Select the correct extension profiles.

? Enable the SCEP autovetting function to enable the CA server to automatically approve certificate requests without manual intervention.

? Specify the IP address list for SCEP autovetting.

Configuring the AC

1. Synchronize the system time of the AC with the CA server for the AC to correctly request certificates or obtain CRLs. (Details not shown.)

2. Create an entity named aaa and set the common name to AC.

<AC> system-view

[AC] pki entity aaa

[AC-pki-entity-aaa] common-name AC

[AC-pki-entity-aaa] quit

3. Configure a PKI domain:

# Create a PKI domain named torsa and enter its view.

[AC] pki domain torsa

# Specify the name of the trusted CA. The setting must be the same as CA name configured on the CA server. This example uses myca.

[AC-pki-domain-torsa] ca identifier myca

# Configure the URL of the CA server. The URL format is http://host:port/Issuing Jurisdiction ID, where Issuing Jurisdiction ID is a hexadecimal string generated on the CA server.

[AC-pki-domain-torsa] certificate request url http://1.1.2.22:446/80f6214aa8865301d07929ae481c7ceed99f95bd

# Configure the AC to send certificate requests to ca.

[AC-pki-domain-torsa] certificate request from ca

# Set the PKI entity name to aaa.

[AC-pki-domain-torsa] certificate request entity aaa

# Specify the URL of the CRL repository.

[AC-pki-domain-torsa] crl url ldap://1.1.2.22:389/CN=myca

# Configure a general-purpose RSA key pair named abc with a length of 1024 bits.

[AC-pki-domain-torsa] public-key rsa general name abc length 1024

[AC-pki-domain-torsa] quit

4. Generate the RSA key pair.

[AC] public-key local create rsa name abc

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512,it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

..........................++++++

.....................................++++++

Create the key pair successfully.

5. Request a local certificate:

# Obtain the CA certificate and save it locally.

[AC] pki retrieve-certificate domain torsa ca

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

Retrieved the certificates successfully.

# Submit a certificate request manually and set the certificate revocation password to 1111. The certificate revocation password is required when an RSA Keon CA server is used.

[AC] pki request-certificate domain torsa password 1111

Start to request the general certificate ...

……

Request certificate of domain torsa successfully

Verifying the configuration

# Display information about the local certificate in PKI domain torsa.

[AC] display pki certificate domain torsa local

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

15:79:75:ec:d2:33:af:5e:46:35:83:bc:bd:6e:e3:b8

Signature Algorithm: sha1WithRSAEncryption

Issuer: CN=myca

Validity

Not Before: Jan 6 03:10:58 2013 GMT

Not After : Jan 6 03:10:58 2014 GMT

Subject: CN=AC

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (1024 bit)

Modulus:

00:ab:45:64:a8:6c:10:70:3b:b9:46:34:8d:eb:1a:

a1:b3:64:b2:37:27:37:9d:15:bd:1a:69:1d:22:0f:

3a:5a:64:0c:8f:93:e5:f0:70:67:dc:cd:c1:6f:7a:

0c:b1:57:48:55:81:35:d7:36:d5:3c:37:1f:ce:16:

7e:f8:18:30:f6:6b:00:d6:50:48:23:5c:8c:05:30:

6f:35:04:37:1a:95:56:96:21:95:85:53:6f:f2:5a:

dc:f8:ec:42:4a:6d:5c:c8:43:08:bb:f1:f7:46:d5:

f1:9c:22:be:f3:1b:37:73:44:f5:2d:2c:5e:8f:40:

3e:36:36:0d:c8:33:90:f3:9b

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 CRL Distribution Points:

Full Name:

DirName: CN = myca

Signature Algorithm: sha1WithRSAEncryption

b0:9d:d9:ac:a0:9b:83:99:bf:9d:0a:ca:12:99:58:60:d8:aa:

73:54:61:4b:a2:4c:09:bb:9f:f9:70:c7:f8:81:82:f5:6c:af:

25:64:a5:99:d1:f6:ec:4f:22:e8:6a:96:58:6c:c9:47:46:8c:

f1:ba:89:b8:af:fa:63:c6:c9:77:10:45:0d:8f:a6:7f:b9:e8:

25:90:4a:8e:c6:cc:b8:1a:f8:e0:bc:17:e0:6a:11:ae:e7:36:

87:c4:b0:49:83:1c:79:ce:e2:a3:4b:15:40:dd:fe:e0:35:52:

ed:6d:83:31:2c:c2:de:7c:e0:a7:92:61:bc:03:ab:40:bd:69:

1b:f5

To display detailed information about the CA certificate, use the display pki certificate domain command.

Requesting a certificate from a Windows Server 2003 CA server

Network requirements

Configure the PKI entity (the AC) to request a local certificate from a Windows Server 2003 CA server.

Figure 85 Network diagram

Configuring the Windows Server 2003 CA server

1. Install the certificate service component:

a. Select Control Panel > Add or Remove Programs from the start menu.

b. Select Add/Remove Windows Components > Certificate Services.

c. Click Next to begin the installation.

d. Set the CA name. In this example, set the CA name to myca.

2. Install the SCEP add-on:

By default, Windows Server 2003 does not support SCEP. You must install the SCEP add-on on the server for a PKI entity to register and obtain a certificate from the server. After the SCEP add-on installation is complete, you will see a URL. Specify this URL as the certificate request URL on the AC.

3. Modify the certificate service attributes:

a. Select Control Panel > Administrative Tools > Certificate Authority from the start menu.

If the certificate service component and SCEP add-on have been installed successfully, there should be two certificates issued by the CA to the RA.

b. Right-click the CA server in the navigation tree and select Properties > Policy Module.

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

a. Select Control Panel > Administrative Tools > Internet Information Services (IIS) Manager from the start menu.

b. Select Web Sites from the navigation tree.

c. Right-click Default Web Site and select Properties > Home Directory.

d. Specify the path for certificate service in the Local path box.

e. Specify a unique TCP port number for the default website to avoid conflict with existing services. In this example, port 8080 is used.

Configuring the AC

1. Synchronize the system time of the AC with the CA server for the AC to correctly request certificates. (Details not shown.)

2. Create an entity named aaa and set the common name to test.

<AC> system-view

[AC] pki entity aaa

[AC-pki-entity-aaa] common-name test

[AC-pki-entity-aaa] quit

3. Configure a PKI domain:

# Create a PKI domain named winserver and enter its view.

[AC] pki domain winserver

# Set the name of the trusted CA to myca.

[AC-pki-domain-winserver] ca identifier myca

# Configure the certificate request URL. The URL format is http://host:port/certsrv/mscep/mscep.dll, where host:port is the host IP address and port number of the CA server.

[AC-pki-domain-winserver] certificate request url http://4.4.4.1:8080/certsrv/mscep/mscep.dll

# Configure the AC to send certificate requests to ra.

[AC-pki-domain-winserver] certificate request from ra

# Set the PKI entity name to aaa.

[AC-pki-domain-winserver] certificate request entity aaa

# Configure a general-purpose RSA key pair named abc with a length of 1024 bits.

[AC-pki-domain-winserver] public-key rsa general name abc length 1024

[AC-pki-domain-winserver] quit

4. Generate the RSA local key pair.

[AC] public-key local create rsa name abc

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512,it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

..........................++++++

.....................................++++++

Create the key pair successfully.

5. Request a local certificate:

# Obtain the CA certificate and save it locally.

[AC] pki retrieve-certificate domain winserver ca

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

Retrieved the certificates successfully.

# Submit a certificate request manually.

[AC] pki request-certificate domain winserver

Start to request the general certificate ...

…

Request certificate of domain winserver successfully

Verifying the configuration

# Display information about the local certificate in PKI domain winserver.

[AC] display pki certificate domain winserver local

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

(Negative)01:03:99:ff:ff:ff:ff:fd:11

Signature Algorithm: sha1WithRSAEncryption

Issuer: CN=sec

Validity

Not Before: Dec 24 07:09:42 2012 GMT

Not After : Dec 24 07:19:42 2013 GMT

Subject: CN=test

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

Modulus:

00:c3:b5:23:a0:2d:46:0b:68:2f:71:d2:14:e1:5a:

55:6e:c5:5e:26:86:c1:5a:d6:24:68:02:bf:29:ac:

dc:31:41:3f:5d:5b:36:9e:53:dc:3a:bc:0d:11:fb:

d6:7d:4f:94:3c:c1:90:4a:50:ce:db:54:e0:b3:27:

a9:6a:8e:97:fb:20:c7:44:70:8f:f0:b9:ca:5b:94:

f0:56:a5:2b:87:ac:80:c5:cc:04:07:65:02:39:fc:

db:61:f7:07:c6:65:4c:e4:5c:57:30:35:b4:2e:ed:

9c:ca:0b:c1:5e:8d:2e:91:89:2f:11:e3:1e:12:8a:

f8:dd:f8:a7:2a:94:58:d9:c7:f8:1a:78:bd:f5:42:

51:3b:31:5d:ac:3e:c3:af:fa:33:2c:fc:c2:ed:b9:

ee:60:83:b3:d3:e5:8e:e5:02:cf:b0:c8:f0:3a:a4:

b7:ac:a0:2c:4d:47:5f:39:4b:2c:87:f2:ee:ea:d0:

c3:d0:8e:2c:80:83:6f:39:86:92:98:1f:d2:56:3b:

d7:94:d2:22:f4:df:e3:f8:d1:b8:92:27:9c:50:57:

f3:a1:18:8b:1c:41:ba:db:69:07:52:c1:9a:3d:b1:

2d:78:ab:e3:97:47:e2:70:14:30:88:af:f8:8e:cb:

68:f9:6f:07:6e:34:b6:38:6a:a2:a8:29:47:91:0e:

25:39

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Key Usage:

Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment

X509v3 Subject Key Identifier:

C9:BB:D5:8B:02:1D:20:5B:40:94:15:EC:9C:16:E8:9D:6D:FD:9F:34

X509v3 Authority Key Identifier:

keyid:32:F1:40:BA:9E:F1:09:81:BD:A8:49:66:FF:F8:AB:99:4A:30:21:9B

X509v3 CRL Distribution Points:

Full Name:

URI:file://\\g07904c\CertEnroll\sec.crl

Authority Information Access:

CA Issuers - URI:http://gc/CertEnroll/gc_sec.crt

CA Issuers - URI:file://\\gc\CertEnroll\gc_sec.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

76:f0:6c:2c:4d:bc:22:59:a7:39:88:0b:5c:50:2e:7a:5c:9d:

6c:28:3c:c0:32:07:5a:9c:4c:b6:31:32:62:a9:45:51:d5:f5:

36:8f:47:3d:47:ae:74:6c:54:92:f2:54:9f:1a:80:8a:3f:b2:

14:47:fa:dc:1e:4d:03:d5:d3:f5:9d:ad:9b:8d:03:7f:be:1e:

29:28:87:f7:ad:88:1c:8f:98:41:9a:db:59:ba:0a:eb:33:ec:

cf:aa:9b:fc:0f:69:3a:70:f2:fa:73:ab:c1:3e:4d:12:fb:99:

31:51:ab:c2:84:c0:2f:e5:f6:a7:c3:20:3c:9a:b0:ce:5a:bc:

0f:d9:34:56:bc:1e:6f:ee:11:3f:7c:b2:52:f9:45:77:52:fb:

46:8a:ca:b7:9d:02:0d:4e:c3:19:8f:81:46:4e:03:1f:58:03:

bf:53:c6:c4:85:95:fb:32:70:e6:1b:f3:e4:10:ed:7f:93:27:

90:6b:30:e7:81:36:bb:e2:ec:f2:dd:2b:bb:b9:03:1c:54:0a:

00:3f:14:88:de:b8:92:63:1e:f5:b3:c2:cf:0a:d5:f4:80:47:

6f:fa:7e:2d:e3:a7:38:46:f6:9e:c7:57:9d:7f:82:c7:46:06:

7d:7c:39:c4:94:41:bd:9e:5c:97:86:c8:48:de:35:1e:80:14:

02:09:ad:08

To display detailed information about the CA certificate, use the display pki certificate domain command.

Requesting a certificate from an OpenCA server

Network requirements

Configure the PKI entity (the AC) to request a local certificate from the CA server.

Figure 86 Network diagram

Configuring the OpenCA server

Configure the OpenCA server as instructed in related manuals. (Details not shown.)

Make sure the version of the OpenCA server is later than version 0.9.2 because the earlier versions do not support SCEP.

Configuring the AC

1. Synchronize the system time of the AC with the CA server for the AC to correctly request certificates. (Details not shown.)

2. Create a PKI entity named aaa and configure the common name, country code, organization name, and OU for the entity.

<AC> system-view

[AC] pki entity aaa

[AC-pki-entity-aaa] common-name rnd

[AC-pki-entity-aaa] country CN

[AC-pki-entity-aaa] organization test

[AC-pki-entity-aaa] organization-unit software

[AC-pki-entity-aaa] quit

3. Configure a PKI domain:

# Create a PKI domain named openca and enter its view.

[AC] pki domain openca

# Specify the name of the trusted CA as myca.

[AC-pki-domain-openca] ca identifier myca

# Configure the certificate request URL. The URL is in the format http://host/cgi-bin/pki/scep, where host is the host IP address of the OpenCA server.

[AC-pki-domain-openca] certificate request url http://192.168.222.218/cgi-bin/pki/scep

# Configure the AC to send certificate requests to the RA.

[AC-pki-domain-openca] certificate request from ra

# Specify PKI entity aaa for certificate request.

[AC-pki-domain-openca] certificate request entity aaa

# Configure a general-purpose RSA key pair named abc with a length of 1024 bits.

[AC-pki-domain-openca] public-key rsa general name abc length 1024

[AC-pki-domain-openca] quit

4. Generate the RSA key pair.

[AC] public-key local create rsa name abc

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512,it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

..........................++++++

.....................................++++++

Create the key pair successfully.

5. Request a local certificate:

# Obtain the CA certificate and save it locally.

[AC] pki retrieve-certificate domain openca ca

The trusted CA's finger print is:

MD5 fingerprint:5AA3 DEFD 7B23 2A25 16A3 14F4 C81C C0FA

SHA1 fingerprint:9668 4E63 D742 4B09 90E0 4C78 E213 F15F DC8E 9122

Is the finger print correct?(Y/N):y

Retrieved the certificates successfully.

# Submit a certificate request manually.

[AC] pki request-certificate domain openca

Start to request the general certificate ...

…

Request certificate of domain openca successfully

Verifying the configuration

# Display information about the local certificate in PKI domain openca.

[AC] display pki certificate domain openca local

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

21:1d:b8:d2:e4:a9:21:28:e4:de

Signature Algorithm: sha256WithRSAEncryption

Issuer: C=CN, L=shangdi, ST=pukras, O=OpenCA Labs, OU=mysubUnit, CN=sub-ca, DC=pki-subdomain, DC=mydomain-sub, DC=com

Validity

Not Before: Jun 30 09:09:09 2011 GMT

Not After : May 1 09:09:09 2012 GMT

Subject: CN=rnd, O=test, OU=software, C=CN

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (1024 bit)

Modulus:

00:b8:7a:9a:b8:59:eb:fc:70:3e:bf:19:54:0c:7e:

c3:90:a5:d3:fd:ee:ff:c6:28:c6:32:fb:04:6e:9c:

d6:5a:4f:aa:bb:50:c4:10:5c:eb:97:1d:a7:9e:7d:

53:d5:31:ff:99:ab:b6:41:f7:6d:71:61:58:97:84:

37:98:c7:7c:79:02:ac:a6:85:f3:21:4d:3c:8e:63:

8d:f8:71:7d:28:a1:15:23:99:ed:f9:a1:c3:be:74:

0d:f7:64:cf:0a:dd:39:49:d7:3f:25:35:18:f4:1c:

59:46:2b:ec:0d:21:1d:00:05:8a:bf:ee:ac:61:03:

6c:1f:35:b5:b4:cd:86:9f:45

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

Netscape Cert Type:

SSL Client, S/MIME

X509v3 Key Usage:

Digital Signature, Non Repudiation, Key Encipherment

X509v3 Extended Key Usage:

TLS Web Client Authentication, E-mail Protection, Microsoft Smartcardlogin

Netscape Comment:

User Certificate of OpenCA Labs

X509v3 Subject Key Identifier:

24:71:C9:B8:AD:E1:FE:54:9A:EA:E9:14:1B:CD:D9:45:F4:B2:7A:1B

X509v3 Authority Key Identifier:

keyid:85:EB:D5:F7:C9:97:2F:4B:7A:6D:DD:1B:4D:DD:00:EE:53:CF:FD:5B

X509v3 Issuer Alternative Name:

DNS:root@docm.com, DNS:, IP Address:192.168.154.145, IP Address:192.168.154.138

Authority Information Access:

CA Issuers - URI:http://192.168.222.218/pki/pub/cacert/cacert.crt

OCSP - URI:http://192.168.222.218:2560/

1.3.6.1.5.5.7.48.12 - URI:http://192.168.222.218:830/

X509v3 CRL Distribution Points:

Full Name:

URI:http://192.168.222.218/pki/pub/crl/cacrl.crl

Signature Algorithm: sha256WithRSAEncryption

5c:4c:ba:d0:a1:35:79:e6:e5:98:69:91:f6:66:2a:4f:7f:8b:

0e:80:de:79:45:b9:d9:12:5e:13:28:17:36:42:d5:ae:fc:4e:

ba:b9:61:f1:0a:76:42:e7:a6:34:43:3e:2d:02:5e:c7:32:f7:

6b:64:bb:2d:f5:10:6c:68:4d:e7:69:f7:47:25:f5:dc:97:af:

ae:33:40:44:f3:ab:e4:5a:a0:06:8f:af:22:a9:05:74:43:b6:

e4:96:a5:d4:52:32:c2:a8:53:37:58:c7:2f:75:cf:3e:8e:ed:

46:c9:5a:24:b1:f5:51:1d:0f:5a:07:e6:15:7a:02:31:05:8c:

03:72:52:7c:ff:28:37:1e:7e:14:97:80:0b:4e:b9:51:2d:50:

98:f2:e4:5a:60:be:25:06:f6:ea:7c:aa:df:7b:8d:59:79:57:

8f:d4:3e:4f:51:c1:34:e6:c1:1e:71:b5:0d:85:86:a5:ed:63:

1e:08:7f:d2:50:ac:a0:a3:9e:88:48:10:0b:4a:7d:ed:c1:03:

9f:87:97:a3:5e:7d:75:1d:ac:7b:6f:bb:43:4d:12:17:9a:76:

b0:bf:2f:6a:cc:4b:cd:3d:a1:dd:e0:dc:5a:f3:7c:fb:c3:29:

b0:12:49:5c:12:4c:51:6e:62:43:8b:73:b9:26:2a:f9:3d:a4:

81:99:31:89

To display detailed information about the CA certificate, use the display pki certificate domain command.

Certificate-based access control policy configuration example

Network requirements

As shown in Figure 87, the client accesses the AC through HTTPS.

Configure a certificate-based access control policy on the AC to authenticate the client and verify the validity of the client's certificate.

Figure 87 Network diagram

Configuration procedure

1. Create the PKI domain domain1 to be used by SSL. (Details not shown.)

2. Request an SSL server certificate for the AC from the CA server. (Details not shown.)

3. Configure the HTTPS server (the AC):

# Configure an SSL server policy named abc for the HTTPS server.

<AC> system-view

[AC] ssl server-policy abc

[AC-ssl-server-policy-abc] pki-domain domain1

[AC-ssl-server-policy-abc] client-verify enable

[AC-ssl-server-policy-abc] quit

# Apply SSL server policy abc to the HTTPS service.

[AC] ip https ssl-server-policy abc

# Enable the HTTPS service.

[AC] ip https enable

4. Configure certificate attribute groups:

# Create a certificate attribute group named mygroup1 and add two attribute rules. The first rule defines that the DN in the subject DN contains the string of aabbcc. The second rule defines 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 a certificate attribute group named mygroup2 and add two attribute rules. The first rule defines that the FQDN in the alternative subject name does not contain the string of apple. The second rule defines that the DN of the certificate issuer name contains the string of 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

5. Configure a certificate-based access control policy:

# Create a certificate-based access control policy named myacp.

[AC] pki certificate access-control-policy myacp

# Define a statement to deny the certificates that match the attribute rules in the certificate attribute group mygroup1.

[AC-pki-cert-acp-myacp] rule 1 deny mygroup1

# Define a statement to permit the certificates that match the attribute rules in the certificate attribute group mygroup2.

[AC-pki-cert-acp-myacp] rule 2 permit mygroup2

[AC-pki-cert-acp-myacp] quit

# Apply certificate-based access control policy myacp to the HTTPS service.

[AC] ip https certificate access-control-policy myacp

Verifying the configuration

# On the host, access the HTTPS server through a Web browser.

The server first verifies the validity of the host's certificate according to the configured certificate-based access control policy. In the host's certificate, the subject DN is aabbcc, the IP address of the certificate issuer is 1.1.1.1, and the FQDN of the alternative subject name is banaba.

The host's certificate does not match the certificate attribute group mygroup1 specified in rule 1 of the certificate-based access control policy. The certificate continues to match against rule 2.

The host's certificate matches the certificate attribute group mygroup2 specified in rule 2. Because rule 2 is a permit statement, the certificate passes the verification and the host can access the HTTPS server.

Certificate import and export configuration example

Network requirements

As shown in Figure 88, AC 2 will replace AC 1 in the network. The PKI domain exportdomain on AC 1 has two local certificates containing the private key and one CA certificate. To make sure the certificates are still valid after AC 2 replaces AC 1, use the following procedure to copy the certificates on AC 1 to AC 2:

1. Export the certificates in PKI domain exportdomain on AC 1 to .pem certificate files.

During the export, encrypt the private key in the local certificates using 3DES_CBC with the password 11111.

2. Transfer the certificate files from AC 1 to AC 2 through the FTP host.

3. Import the certificate files to PKI domain importdomain on AC 2.

Figure 88 Network diagram

Configuration procedure

1. Export the certificates on AC 1:

# Export the CA certificate to a .pem file.

<AC1> system-view

[AC1] pki export domain exportdomain pem ca filename pkicachain.pem

# Export the local certificate to a file named pkilocal.pem in PEM format, and use 3DES_CBC to encrypt the private key with the password 111111.

[AC1] pki export domain exportdomain pem local 3des-cbc 111111 filename pkilocal.pem

Now, AC 1 has three certificate files in PEM format:

? A CA certificate file named pkicachain.pem.

? A local certificate file named pkilocal.pem-signature, which contains the private key for signature.

? A local certificate file named pkilocal.pem-encryption, which contains the private key for encryption.

# Display the local certificate file pkilocal.pem-signature.

[AC1] quit

<AC1> more pkicachain.pem-sign

Bag Attributes

friendlyName:

localKeyID: 90 C6 DC 1D 20 49 4F 24 70 F5 17 17 20 2B 9E AC 20 F3 99 89

subject=/C=CN/O=OpenCA Labs/OU=Users/CN=subsign 11

issuer=/C=CN/L=shangdi/ST=pukras/O=OpenCA Labs/OU=docm/CN=subca1

-----BEGIN CERTIFICATE-----

MIIEgjCCA2qgAwIBAgILAJgsebpejZc5UwAwDQYJKoZIhvcNAQELBQAwZjELMAkG

…

-----END CERTIFICATE-----

Bag Attributes

friendlyName:

localKeyID: 90 C6 DC 1D 20 49 4F 24 70 F5 17 17 20 2B 9E AC 20 F3 99 89

Key Attributes: <No Attributes>

-----BEGIN ENCRYPTED PRIVATE KEY-----

MIICxjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIZtjSjfslJCoCAggA

…

-----END ENCRYPTED PRIVATE KEY-----

# Display the local certificate file pkilocal.pem-encryption.

<AC1> more pkicachain.pem-encr

Bag Attributes

friendlyName:

localKeyID: D5 DF 29 28 C8 B9 D9 49 6C B5 44 4B C2 BC 66 75 FE D6 6C C8

subject=/C=CN/O=OpenCA Labs/OU=Users/CN=subencr 11

issuer=/C=CN/L=shangdi/ST=pukras/O=OpenCA Labs/OU=docm/CN=subca1

-----BEGIN CERTIFICATE-----

MIIEUDCCAzigAwIBAgIKCHxnAVyzWhIPLzANBgkqhkiG9w0BAQsFADBmMQswCQYD

…

-----END CERTIFICATE-----

Bag Attributes

friendlyName:

localKeyID: D5 DF 29 28 C8 B9 D9 49 6C B5 44 4B C2 BC 66 75 FE D6 6C C8

Key Attributes: <No Attributes>

-----BEGIN ENCRYPTED PRIVATE KEY-----

MIICxjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQI7H0mb4O7/GACAggA

…

-----END ENCRYPTED PRIVATE KEY-----

2. Download the certificate files pkicachain.pem, pkilocal.pem-sign, and pkilocal.pem-encr from AC 1 to the client through FTP. (Details not shown.)

3. Upload the certificate files pkicachain.pem, pkilocal.pem-sign, and pkilocal.pem-encr from the client to AC 2 through FTP. (Details not shown.)

4. Import the certificate files to AC 2:

# Disable CRL checking. (You can configure CRL checking as required. This example assumes CRL checking is not required.)

<AC2> system-view

[AC2] pki domain importdomain

[AC2-pki-domain-importdomain] undo crl check enable

# Specify the RSA key pair for signature as sign, and the RSA key pair for encryption as encr for certificate request.

[AC2-pki-domain-importdomain] public-key rsa signature name sign encryption name encr

[AC2-pki-domain-importdomain] quit

# Import the CA certificate file pkicachain.pem in PEM format to the PKI domain.

[AC2] pki import domain importdomain pem ca filename pkicachain.pem

# Import the local certificate file pkilocal.pem-signature in PEM format to the PKI domain. The certificate file contains a key pair.

[AC2] pki import domain importdomain pem local filename pkilocal.pem-signature

Please input the password:******

# Import the local certificate file pkilocal.pem-encryption in PEM format to the PKI domain. The certificate file contains a key pair.

[AC2] pki import domain importdomain pem local filename pkilocal.pem-encryption

Please input the password:******

# Display the imported local certificate information on AC 2.

[AC2] display pki certificate domain importdomain local

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

98:2c:79:ba:5e:8d:97:39:53:00

Signature Algorithm: sha256WithRSAEncryption

Issuer: C=CN, L=shangdi, ST=pukras, O=OpenCA Labs, OU=docm, CN=subca1

Validity

Not Before: May 26 05:56:49 2011 GMT

Not After : Nov 22 05:56:49 2012 GMT

Subject: C=CN, O=OpenCA Labs, OU=Users, CN=subsign 11

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (1024 bit)

Modulus:

00:9f:6e:2f:f6:cb:3d:08:19:9a:4a:ac:b4:ac:63:

ce:8d:6a:4c:3a:30:19:3c:14:ff:a9:50:04:f5:00:

ee:a3:aa:03:cb:b3:49:c4:f8:ae:55:ee:43:93:69:

6c:bf:0d:8c:f4:4e:ca:69:e5:3f:37:5c:83:ea:83:

ad:16:b8:99:37:cb:86:10:6b:a0:4d:03:95:06:42:

ef:ef:0d:4e:53:08:0a:c9:29:dd:94:28:02:6e:e2:

9b:87:c1:38:2d:a4:90:a2:13:5f:a4:e3:24:d3:2c:

bf:98:db:a7:c2:36:e2:86:90:55:c7:8c:c5:ea:12:

01:31:69:bf:e3:91:71:ec:21

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

Netscape Cert Type:

SSL Client, S/MIME

X509v3 Key Usage:

Digital Signature, Non Repudiation

X509v3 Extended Key Usage:

TLS Web Client Authentication, E-mail Protection, Microsoft Smartcardlogin

Netscape Comment:

User Certificate of OpenCA Labs

X509v3 Subject Key Identifier:

AA:45:54:29:5A:50:2B:89:AB:06:E5:BD:0D:07:8C:D9:79:35:B1:F5

X509v3 Authority Key Identifier:

keyid:70:54:40:61:71:31:02:06:8C:62:11:0A:CC:A5:DB:0E:7E:74:DE:DD

X509v3 Subject Alternative Name:

email:subsign@docm.com

X509v3 Issuer Alternative Name:

DNS:subca1@docm.com, DNS:, IP Address:1.1.2.2, IP Address:2.2.1.1

Authority Information Access:

CA Issuers - URI:http://titan/pki/pub/cacert/cacert.crt

OCSP - URI:http://titan:2560/

1.3.6.1.5.5.7.48.12 - URI:http://titan:830/

X509v3 CRL Distribution Points:

Full Name:

URI:http://192.168.40.130/pki/pub/crl/cacrl.crl

Signature Algorithm: sha256WithRSAEncryption

18:e7:39:9a:ad:84:64:7b:a3:85:62:49:e5:c9:12:56:a6:d2:

46:91:53:8e:84:ba:4a:0a:6f:28:b9:43:bc:e7:b0:ca:9e:d4:

1f:d2:6f:48:c4:b9:ba:c5:69:4d:90:f3:15:c4:4e:4b:1e:ef:

2b:1b:2d:cb:47:1e:60:a9:0f:81:dc:f2:65:6b:5f:7a:e2:36:

29:5d:d4:52:32:ef:87:50:7c:9f:30:4a:83:de:98:8b:6a:c9:

3e:9d:54:ee:61:a4:26:f3:9a:40:8f:a6:6b:2b:06:53:df:b6:

5f:67:5e:34:c8:c3:b5:9b:30:ee:01:b5:a9:51:f9:b1:29:37:

02:1a:05:02:e7:cc:1c:fe:73:d3:3e:fa:7e:91:63:da:1d:f1:

db:28:6b:6c:94:84:ad:fc:63:1b:ba:53:af:b3:5d:eb:08:b3:

5b:d7:22:3a:86:c3:97:ef:ac:25:eb:4a:60:f8:2b:a3:3b:da:

5d:6f:a5:cf:cb:5a:0b:c5:2b:45:b7:3e:6e:39:e9:d9:66:6d:

ef:d3:a0:f6:2a:2d:86:a3:01:c4:94:09:c0:99:ce:22:19:84:

2b:f0:db:3e:1e:18:fb:df:56:cb:6f:a2:56:35:0d:39:94:34:

6d:19:1d:46:d7:bf:1a:86:22:78:87:3e:67:fe:4b:ed:37:3d:

d6:0a:1c:0b

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

08:7c:67:01:5c:b3:5a:12:0f:2f

Signature Algorithm: sha256WithRSAEncryption

Issuer: C=CN, L=shangdi, ST=pukras, O=OpenCA Labs, OU=docm, CN=subca1

Validity

Not Before: May 26 05:58:26 2011 GMT

Not After : Nov 22 05:58:26 2012 GMT

Subject: C=CN, O=OpenCA Labs, OU=Users, CN=subencr 11

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (1024 bit)

Modulus:

00:db:26:13:d3:d1:a4:af:11:f3:6d:37:cf:d0:d4:

48:50:4e:0f:7d:54:76:ed:50:28:c6:71:d4:48:ae:

4d:e7:3d:23:78:70:63:18:33:f6:94:98:aa:fa:f6:

62:ed:8a:50:c6:fd:2e:f4:20:0c:14:f7:54:88:36:

2f:e6:e2:88:3f:c2:88:1d:bf:8d:9f:45:6c:5a:f5:

94:71:f3:10:e9:ec:81:00:28:60:a9:02:bb:35:8b:

bf:85:75:6f:24:ab:26:de:47:6c:ba:1d:ee:0d:35:

75:58:10:e5:e8:55:d1:43:ae:85:f8:ff:75:81:03:

8c:2e:00:d1:e9:a4:5b:18:39

Exponent: 65537 (0x10001)

X509v3 extensions:

X509v3 Basic Constraints:

CA:FALSE

Netscape Cert Type:

SSL Server

X509v3 Key Usage:

Key Encipherment, Data Encipherment

Netscape Comment:

VPN Server of OpenCA Labs

X509v3 Subject Key Identifier:

CC:96:03:2F:FC:74:74:45:61:38:1F:48:C0:E8:AA:18:24:F0:2B:AB

X509v3 Authority Key Identifier:

keyid:70:54:40:61:71:31:02:06:8C:62:11:0A:CC:A5:DB:0E:7E:74:DE:DD

X509v3 Subject Alternative Name:

email:subencr@docm.com

X509v3 Issuer Alternative Name:

DNS:subca1@docm.com, DNS:, IP Address:1.1.2.2, IP Address:2.2.1.1

Authority Information Access:

CA Issuers - URI:http://titan/pki/pub/cacert/cacert.crt

OCSP - URI:http://titan:2560/

1.3.6.1.5.5.7.48.12 - URI:http://titan:830/

X509v3 CRL Distribution Points:

Full Name:

URI:http://192.168.40.130/pki/pub/crl/cacrl.crl

Signature Algorithm: sha256WithRSAEncryption

53:69:66:5f:93:f0:2f:8c:54:24:8f:a2:f2:f1:29:fa:15:16:

90:71:e2:98:e3:5c:c6:e3:d4:5f:7a:f6:a9:4f:a2:7f:ca:af:

c4:c8:c7:2c:c0:51:0a:45:d4:56:e2:81:30:41:be:9f:67:a1:

23:a6:09:50:99:a1:40:5f:44:6f:be:ff:00:67:9d:64:98:fb:

72:77:9e:fd:f2:4c:3a:b2:43:d8:50:5c:48:08:e7:77:df:fb:

25:9f:4a:ea:de:37:1e:fb:bc:42:12:0a:98:11:f2:d9:5b:60:

bc:59:72:04:48:59:cc:50:39:a5:40:12:ff:9d:d0:69:3a:5e:

3a:09:5a:79:e0:54:67:a0:32:df:bf:72:a0:74:63:f9:05:6f:

5e:28:d2:e8:65:49:e6:c7:b5:48:7d:95:47:46:c1:61:5a:29:

90:65:45:4a:88:96:e4:88:bd:59:25:44:3f:61:c6:b1:08:5b:

86:d2:4f:61:4c:20:38:1c:f4:a1:0b:ea:65:87:7d:1c:22:be:

b6:17:17:8a:5a:0f:35:4c:b8:b3:73:03:03:63:b1:fc:c4:f5:

e9:6e:7c:11:e8:17:5a:fb:39:e7:33:93:5b:2b:54:72:57:72:

5e:78:d6:97:ef:b8:d8:6d:0c:05:28:ea:81:3a:06:a0:2e:c3:

79:05:cd:c3

To display detailed information about the CA certificate, use the display pki certificate domain command.

Troubleshooting PKI configuration

This section provides troubleshooting information for common problems with PKI.

Failed to obtain the CA certificate

Symptom

The CA certificate cannot be obtained.

Analysis

· The network connection is down, for example, because the network cable is damaged or the connectors have bad contact.

· No trusted CA is specified.

· The certificate request URL is incorrect or not specified.

· The system time of the device is not synchronized with the CA server.

· The source IP address of the PKI protocol packets is not specified or is incorrect.

· The fingerprint of the root CA certificate is illegal.

Solution

1. Check for and fix any network connection problems.

2. Verify that the required configurations are correct.

3. Use ping to verify that the registration server is reachable.

4. Synchronize the system time of the device with the CA server.

5. Specify the correct source IP address for PKI protocol packets that the CA server can accept.

6. Verify the CA certificate's fingerprint on the CA server.

7. If the problem persists, contact H3C Support.

Failed to obtain local certificates

Symptom

No local certificates can be obtained.

Analysis

· The network connection is down.

· No CA certificate has been obtained before you try to obtain local certificates.

· The LDAP server is not configured or is incorrectly configured.

· No key pair is specified for the PKI domain for certificate request, or the specified key pair does not match the local certificates to the obtained.

· The PKI domain does not reference the PKI entity configuration, or the PKI entity configuration is incorrect.

· CRL checking is enabled, but CRLs do not exist locally or CRLs cannot be obtained.

· The CA server does not accept the source IP address specified in the PKI domain, or the source IP address is incorrect.

· The system time of the device is not synchronized with the CA server.

Solution

1. Check for and fix any network connection problems.

2. Obtain or import the CA certificate.

3. Configure the correct LDAP server.

4. Specify the key pair used for certificate request in the PKI domain, or remove the existing key pair and submit a certificate request again.

5. Check the registration policy on the CR or RA, and make sure the attributes of the PKI entity meet the policy requirements.

6. Obtain the CRL from the CRL repository.

7. Specify the correct source IP address that the CA server can accept. For the correct settings, contact the CA administrator.

8. Synchronize the system time of the device with the CA server.

9. If the problem persists, contact H3C Support.

Failed to request local certificates

Symptom

Local certificate requests cannot be submitted.

Analysis

· The network connection is down, for example, because the network cable is damaged or the connectors have bad contact.

· No CA certificate has been obtained before you submit the certificate request.

· The certificate request URL is incorrect or is not specified.

· The certificate request reception authority is incorrect or is not specified.

· The required parameters are not configured for the PKI entity or are mistakenly configured.

· No key pair is specified for the PKI domain for certificate request, or the key pair is changed during a certificate request process.

· Exclusive certificate request applications are running in the PKI domain.

· The PKI domain is not specified with the source IP address that the CA server can accept, or is specified with an incorrect one.

· The system time of the device is not synchronized with the CA server.

Solution

1. Check for and fix any network connection problems.

2. Obtain or import the CA certificate.

3. Use ping to verify that the registration server is reachable.

4. Specify the correct certificate request URL.

5. Check the registration policy on the CR or RA, and make sure the attributes of the PKI entity meet the policy requirements.

6. Specify the key pair used for certificate request in the PKI domain, or remove the key pair specified in the PKI and submit a certificate request again.

7. Use pki abort-certificate-request domain to abort the certificate request.

8. Specify the correct source IP address that the CA server can accept. For the correct settings, contact the CA administrator.

9. Synchronize the system time of the device with the CA server.

10. If the problem persists, contact H3C Support.

Failed to obtain CRLs

Symptom

CRLs cannot be obtained.

Analysis

· The network connection is down, for example, because the network cable is damaged or the connectors have bad contact.

· No CA certificate has been obtained before you try to obtain CRLs.

· The URL of the CRL repository is not configured and cannot be obtained from the CA certificate or local certificates in the PKI domain.

· The specified URL of the CRL repository is incorrect.

· The device tries to obtain CRLs through SCEP, but experiences the following problems:

? The PKI domain does not have local certificates.

? The key pairs in the certificates have been changed.

? The PKI domain has incorrect URL for certificate request.

· The specified URL of the CRL repository does not contain the host name or IP address, and the LDAP server is incorrect or is not specified in the PKI domain.

· The CA does not issue CRLs.

· The PKI domain is not specified with the source IP address that the CA server can accept, or is specified with an incorrect one.

Solution

1. Check for and fix any network connection problems.

2. Obtain or import the CA certificate.

3. If the URL of the CRL repository cannot be obtained, verify that the following conditions exist:

? The URL for certificate request is valid.

? A local certificate has been successfully obtained.

? The local certificate contains a public key that matches the locally stored key pair.

4. Make sure the LDAP server address is contained in the CRL repository URL, or is configured in the PKI domain.

5. Make sure the CA server support publishing CRLs.

6. Specify a correct source IP address that the CA server can accept. For the correct settings, contact the CA administrator.

7. If the problem persists, contact H3C Support.

Failed to import the CA certificate

Symptom

The CA certificate cannot be imported.

Analysis

· CRL checking is enabled, but the device does not have a locally stored CRL and cannot obtain one.

· The specified format does not match the actual format of the file to be imported.

Solution

1. Use undo crl check enable to disable CRL checking.

2. Make sure the format of the imported file is correct.

3. If the problem persists, contact H3C Support.

Failed to import a local certificate

Symptom

A local certificate cannot be imported.

Analysis

· The PKI domain has no CA certificate, and the certificate file to be imported does not contain the CA certificate chain.

· CRL checking is enabled, but the device does not have a locally stored CRL and cannot obtain one.

· The specified format does not match the actual format of the file to be imported.

· The device and the certificate do not have the local key pair.

· The certificate has been revoked.

· The certificate is out of the validity period.

· The system time is wrong.

Solution

1. Obtain or import the CA certificate.

2. Use undo crl check enable to disable CRL checking, or obtain the correct CRL before you import certificates.

3. Make sure the format of the file to be imported is correct.

4. Make sure the certificate file contains the private key.

5. Make sure the certificate is not revoked.

6. Make sure the certificate is valid.

7. Configure the correct system time for the device.

8. If the problem persists, contact H3C Support.

Failed to export certificates

Symptom

Certificates cannot be exported.

Analysis

· The PKI domain does not have local certificates when you export all certificates in PKCS12 format.

· The specified export path does not exist.

· The specified export path is illegal.

· The public key of the local certificate to be exported does not match the public key in the key pair of the PKI domain.

· The storage space of the device is full.

Solution

1. If the PKI domain does not have local certificates, obtain or request local certificates first.

2. Use mkdir to create the required path.

3. Specify a correct export path.

4. Configure the correct key pair in the PKI domain.

5. Clear up the storage space of the device.

6. If the problem persists, contact H3C Support.

Failed to set the storage path

Symptom

The storage path for certificates or CRLs cannot be set.

Analysis

· The specified storage path does not exist.

· The specified storage path is illegal.

· The storage space of the device is full.

Solution

1. Use mkdir to create the path.

2. Specify a valid storage path for certificates or CRLs.

3. Clear up the storage space of the device.

4. If the problem persists, contact H3C Support.

Configuring IPsec

Overview

IP Security (IPsec) is defined by the IETF to provide interoperable, high-quality, cryptography-based security for IP communications. It is a Layer 3 VPN technology that transmits data in a secure channel established between two endpoints (such as two security gateways). Such a secure channel is usually called an IPsec tunnel.

IPsec is a security framework that has the following protocols and algorithms:

· Authentication Header (AH).

· Encapsulating Security Payload (ESP).

· Internet Key Exchange (IKE).

· Algorithms for authentication and encryption.

AH and ESP are security protocols that provide security services. IKE performs automatic key exchange. For more information about IKE, see "Configuring IKE."

IPsec provides the following security services for data packets in the IP layer:

· Confidentiality—The sender encrypts packets before transmitting them over the Internet, protecting the packets from being eavesdropped en route.

· Data integrity—The receiver verifies the packets received from the sender to make sure they are not tampered with during transmission.

· Data origin authentication—The receiver verifies the authenticity of the sender.

· Anti-replay—The receiver examines packets and drops outdated and duplicate packets.

IPsec delivers the following benefits:

· Reduced key negotiation overhead 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.

Security protocols and encapsulation modes

Security protocols

IPsec comes with two security protocols, AH and ESP. They define how to encapsulate IP packets and the security services that they can provide.

· AH (protocol 51) defines the encapsulation of the AH header in an IP packet, as shown in Figure 91. AH can provide data origin authentication, data integrity, and anti-replay services to prevent data tampering, but it cannot prevent eavesdropping. Therefore, it is suitable for transmitting non-confidential data. AH supports authentication algorithms HMAC-MD5 and HMAC-SHA1.

· ESP (protocol 50) defines the encapsulation of the ESP header and trailer in an IP packet, as shown in Figure 91. ESP can provide data encryption, data origin authentication, data integrity, and anti-replay services. Unlike AH, ESP can guarantee data confidentiality because it can encrypt the data before encapsulating the data to IP packets. ESP supports encryption algorithms such as DES, 3DES, and AES, and authentication algorithms HMAC-MD5 and HMAC-SHA1.

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.

Encapsulation modes

IPsec supports the following encapsulation modes:

· Transport mode—The security protocols protect the upper layer data of an IP packet. Only the transport layer data is used to calculate the security protocol headers. The calculated security protocol headers and the encrypted data (only for ESP encapsulation) are placed after the original IP header. You can use the transport mode when end-to-end security protection is required (the secured transmission start and end points are the actual start and end points of the data). The transport mode is typically used for protecting host-to-host communications, as shown in Figure 89.

Figure 89 IPsec protection in transport mode

· Tunnel mode—The security protocols protect the entire IP packet. The entire IP packet is used to calculate the security protocol headers. The calculated security protocol headers and the encrypted data (only for ESP encapsulation) are encapsulated in a new IP packet. In this mode, the encapsulated packet has two IP headers. The inner IP header is the original IP header. The outer IP header is added by the network device that provides the IPsec service. You must use the tunnel mode when the secured transmission start and end points are not the actual start and end points of the data packets (for example, when two gateways provide IPsec but the data start and end points are two hosts behind the gateways). The tunnel mode is typically used for protecting gateway-to-gateway communications, as shown in Figure 90.

Figure 90 IPsec protection in tunnel mode

Figure 91 shows how the security protocols encapsulate an IP packet in different encapsulation modes.

Figure 91 Security protocol encapsulations in different modes

Security association

A security association (SA) is an agreement negotiated between two communicating parties called IPsec peers. An SA includes the following parameters for data protection:

· Security protocols (AH, ESP, or both).

· Encapsulation mode (transport mode or tunnel mode).

· Authentication algorithm (HMAC-MD5 or HMAC-SHA1).

· Encryption algorithm (DES, 3DES, or AES).

· Shared keys and their lifetimes.

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 in each direction.

An SA is uniquely identified by a triplet, which consists of the security parameter index (SPI), destination IP address, and security protocol identifier. An SPI is a 32-bit number. It is transmitted in the AH/ESP header.

An SA can be set up manually or through IKE.

· Manual mode—Configure all parameters for the SA through commands. This configuration mode is complex and does not support some advanced features (such as periodic key update), but it can implement IPsec without IKE. This mode is mainly used in small and static networks or when the number of IPsec peers in the network is small.

· IKE negotiation mode—The peers negotiate and maintain the SA through IKE. This configuration mode is simple and has good expansibility. In medium- and large-scale dynamic networks, H3C recommends setting up SAs through IKE negotiations.

A manually configured SA never ages out. An IKE-created SA has a lifetime, which comes in two types:

· Time-based lifetime—Defines how long the SA can be valid after it is created.

· Traffic-based lifetime—Defines the maximum traffic that the SA can process.

If both lifetime timers are configured for an SA, 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.

Authentication and encryption

Authentication algorithms

IPsec uses hash algorithms to perform authentication. A hash algorithm produces a fixed-length digest for an arbitrary-length message. IPsec peers respectively calculate message digests for each packet. The receiver compares the local digest with that received from the sender. If the digests are identical, the receiver considers the packet intact and the sender's identity valid. IPsec uses the Hash-based Message Authentication Code (HMAC) based authentication algorithms, including HMAC-MD5 and HMAC-SHA1. Compared with HMAC-SHA1, HMAC-MD5 is faster but less secure.

Encryption algorithms

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

· DES—Encrypts a 64-bit plaintext block with a 56-bit key. DES is the least secure but the fastest algorithm.

· 3DES—Encrypts plaintext 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.

· AES—Encrypts plaintext data with a 128-bit, 192-bit, or 256-bit key. AES provides the highest security strength and is slower than 3DES.

Crypto engine

The IPsec feature is resource intensive for its complex encryption/decryption and authentication algorithms. To improve processing performance, you can use crypto engine to offload IPsec tasks.

The crypto engine processes all IPsec-protected packets and hands the processed packets back to the device for forwarding.

For more information about crypto engines, see "Configuring crypto engines."

IPsec implementation

To implement IPsec protection for packets between two peers, complete the following tasks on each peer:

· Configure an IPsec policy, which defines the range of packets to be protected by IPsec and the security parameters used for the protection.

· Apply the IPsec policy to an interface.

When you apply an IPsec policy to an interface, you implement IPsec based on the interface. Packets received and sent by the interface are protected according to the IPsec policy.

IPsec protects packets as follows:

· When an IPsec peer identifies the packets to be protected according to the IPsec policy, it sets up an IPsec tunnel and sends the packet to the remote peer through the tunnel. The IPsec tunnel can be manually configured beforehand, or it can be set up through IKE negotiation triggered by the packet. The IPsec tunnels are actually the IPsec SAs. The inbound packets are protected by the inbound SA, and the outbound packets are protected by the outbound SA.

· When the remote IPsec peer receives the packet, it drops, de-encapsulates, or directly forwards the packet according to the configured IPsec policy.

Interface-based IPsec supports setting up IPsec tunnels based on ACLs.

To implement ACL-based IPsec, configure an ACL to define the data flows to be protected, specify the ACL in an IPsec policy, and then apply the IPsec policy to an interface. When packets sent by the interface match a permit rule of the ACL, the packets are protected by the outbound IPsec SA and encapsulated with IPsec. When the interface receives an IPsec packet destined for the local device, it searches for the inbound IPsec SA according to the SPI in the IPsec packet header for de-encapsulation. If the de-encapsulated packet matches a permit rule of the ACL, the device processes the packet. If the de-encapsulated packet does not match any permit rule of the ACL, the device drops the packet.

The device supports the following data flow protection modes:

· Standard mode—One IPsec tunnel protects one data flow. The data flow permitted by an ACL rule is protected by one IPsec tunnel that is established solely for it.

· Aggregation mode—One IPsec tunnel protects all data flows permitted by all the rules of an ACL. This mode is only used to communicate with old-version devices.

· Per-host mode—One IPsec tunnel protects one host-to-host data flow. One host-to-host data flow is identified by one ACL rule and protected by one IPsec tunnel established solely for it. This mode consumes more system resources when multiple data flows exist between two subnets to be protected.

IPsec RRI

As shown in Figure 92, the traffic between the enterprise center and the branches are protected by IPsec. The gateway at the enterprise center is configured with static routes to route traffic to the IPsec-protected interfaces. It is difficult to add or modify static routes on the gateway at the enterprise center if the IPsec VPN has a large number of branches or if the network structure changes.

Figure 92 IPsec VPN

IPsec Reverse Route Injection (RRI) enables an IPsec tunnel gateway to automatically add static routes destined for protected private networks or static routes destined for peer IPsec tunnel gateways to a routing table. As shown in Figure 92, you can enable IPsec RRI on the gateway at the enterprise center. After an IPsec tunnel is established, the gateway automatically adds a static route to the routing table, which can be looked up. The destination IP address is the protected private network, and the next hop is the remote IP address of the IPsec tunnel. The traffic destined for the peer end is routed to the IPsec tunnel interface and thereby protected by IPsec.

You can advertise the static routes created by IPsec RRI in the internal network, and the internal network device can use them to forward traffic in the IPsec VPN.

IPsec RRI is applicable to gateways that must provide many IPsec tunnels (for example, a headquarters gateway).

Protocols and standards

· RFC 2401, Security Architecture for the Internet Protocol

· RFC 2402, IP Authentication Header

· RFC 2406, IP Encapsulating Security Payload

· RFC 4552, Authentication/Confidentiality for OSPFv3

IPsec tunnel establishment

CAUTION:

Typically, IKE uses UDP port 500 for communication, and AH and ESP use the protocol numbers 51 and 50, respectively. Make sure traffic of these protocols is not denied on the interfaces with IKE or IPsec configured.

An ACL-based IPsec tunnel protects packets identified by an ACL. To establish an ACL-based IPsec tunnel, configure an IPsec policy, specify an ACL in the policy, and apply the policy to an interface (see "Implementing ACL-based IPsec"). The IPsec tunnel establishment steps are the same in an IPv4 network and in an IPv6 network.

Feature and hardware compatibility

Hardware series	Model	IPsec compatibility
WX1800H series	WX1804H	Yes
	WX1810H	Yes
	WX1820H	Yes
	WX1840H	No
WX3800H series	WX3820H WX3840H	No
WX5800H series	WX5860H	No

Implementing ACL-based IPsec

Use the following procedure to implement ACL-based IPsec:

1. Configure an ACL for identifying data flows to be protected. To use IPsec to protect VPN traffic, you do not need to specify the VPN parameters in the ACL rules.

2. Configure IPsec transform sets to specify the security protocols, authentication and encryption algorithms, and the encapsulation mode.

3. Configure an IPsec policy to associate data flows with the IPsec transform sets, specify the SA negotiation mode, the peer IP addresses (the start and end points of the IPsec tunnel), the required keys, and the SA lifetime.

An IPsec policy is a set of IPsec policy entries that have the same name but different sequence numbers. In the same IPsec policy, an IPsec policy entry with a smaller sequence number has a higher priority.

4. Apply the IPsec policy to an interface.

Complete the following tasks to configure ACL-based IPsec:

Tasks at a glance
(Required.) Configuring an ACL
(Required.) Configuring an IPsec transform set
(Required.) Configure an IPsec policy (use either method): · Configuring a manual IPsec policy · Configuring an IKE-based IPsec policy
(Required.) Applying an IPsec policy to an interface
(Optional.) Enabling ACL checking for de-encapsulated packets
(Optional.) Configuring IPsec anti-replay
(Optional.) Configuring IPsec anti-replay redundancy
(Optional.) Binding a source interface to an IPsec policy
(Optional.) Enabling QoS pre-classify
(Optional.) Enabling logging of IPsec packets
(Optional.) Configuring the DF bit of IPsec packets
(Optional.) Configuring IPsec RRI
(Optional.) Configuring SNMP notifications for IPsec
(Optional.) Configuring IPsec fragmentation
(Optional.) Setting the maximum number of IPsec tunnels
(Optional.) Enabling logging for IPsec negotiation

Configuring an ACL

IPsec uses ACLs to identify the traffic to be protected.

Keywords in ACL rules

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. IPsec compares a packet against the ACL rules and processes the packet according to the first rule it matches.

· 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 delivers it to the next 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. By default, the de-encapsulated packets are compared against the ACL rules. Only those that match a permit statement are processed. Other packets are dropped. If ACL checking for de-encapsulated IPsec packets is disabled, the de-encapsulated packets are not compared against the ACL rules and are directly processed by other modules.

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 will be protected by IPsec. All inbound IPsec packets matching the permit statement will be received and processed, but all inbound non-IPsec packets will be dropped. This will cause all the inbound traffic that does not need IPsec protection to be dropped.

· Avoid statement conflicts in the scope of IPsec policy entries. When creating a deny statement, be careful with its match scope and match order relative to permit statements. The policy entries in an IPsec policy 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 entry 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 entry. Otherwise, the packets will be sent out as normal packets. If they match a permit statement at the receiving end, they will be dropped by IPsec.

The following example shows how an improper statement causes unexpected packet dropping. Only the ACL-related configuration is presented.

Assume Router A is connected to subnet 1.1.2.0/24 and Router B is connected to subnet 3.3.3.0/24, and the IPsec policy configuration on Router A and Router B is as follows:

· IPsec configuration on Router A:

acl advanced 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 advanced 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 testa 1 isakmp <---IPsec policy entry with a higher priority

security acl 3000

ike-profile aa

transform-set 1

ipsec policy testa 2 isakmp <---IPsec policy entry with a lower priority

security acl 3001

ike-profile bb

transform-set 1

· IPsec configuration on Router B:

acl advanced 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 testb 1 isakmp

security acl 3001

ike-profile aa

transform-set 1

On Router A, apply the IPsec policy testa to the outbound interface of Router A. The IPsec policy contains two policy entries, testa 1 and testa 2. The ACLs used by the two policy entries each contain a rule that matches traffic from 1.1.2.0/24 to 3.3.3.0/24. The one used in policy entry testa 1 is a deny statement and the one used in policy entry testa 2 is a permit statement. Because testa 1 is matched prior to testa 2, traffic from 1.1.2.0/24 to 3.3.3.0/24 will match the deny statement and be sent as normal traffic. When the traffic arrives at Router B, the traffic matches rule 0 (a permit statement) in ACL 3001 used in the applied IPsec policy testb. Because non-IPsec traffic that matches a permit statement must be dropped on the inbound interface, Router B drops the traffic.

To make sure subnet 1.1.2.0/24 can access subnet 3.3.3.0/24, you can delete the deny rule in ACL 3000 on Router A.

Mirror image ACLs

To make sure SAs can be set up and the traffic protected by IPsec can be processed correctly between two IPsec peers, create mirror image ACLs on the IPsec peers. As shown in Figure 93, ACL rules on Router B are mirror images of the rules on Router A. In this way, SAs can be created successfully for the traffic between Host A and Host C and for the traffic between Network 1 and Network 2.

Figure 93 Mirror image ACLs

If the ACL rules on IPsec 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 94, 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 94, the SA negotiation initiated by Host A to Host C is accepted but the SA negotiations from Host C to Host A, from Host C to Host B, and from Host D to Host A are rejected.

Figure 94 Non-mirror image ACLs

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, encryption algorithms, and authentication algorithms.

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 by using the updated parameters.

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 sets exist.
3. Specify the security protocol for the IPsec transform set.	protocol { ah \| ah-esp \| esp }	Optional. By default, the IPsec transform set uses ESP as the security protocol.
4. Specify the security algorithms.	· Specify the encryption algorithm for ESP: esp encryption-algorithm { 3des-cbc \| aes-cbc-128 \| aes-cbc-192 \| aes-cbc-256 \| aes-ctr-128 \| aes-ctr-192 \| aes-ctr-256 \| camellia-cbc-128 \| camellia-cbc-192 \| camellia-cbc-256 \| des-cbc \| gmac-128 \| gmac-192 \| gmac-256 \| gcm-128 \| gcm-192 \| gcm-256 \| null } * · Specify the authentication algorithm for ESP: esp authentication-algorithm { aes-xcbc-mac \| md5 \| sha1 \| sha256 \| sha384 \| sha512 } * · Specify the authentication algorithm for AH: ah authentication-algorithm { aes-xcbc-mac \| md5 \| sha1 \| sha256 \| sha384 \| sha512 } *	Configure at least one command. By default, no security algorithm is specified. You can specify security algorithms for a security protocol only when the security protocol is used by the transform set. For example, you can specify the ESP-specific security algorithms only when you select ESP or AH-ESP as the security protocol. You can specify multiple algorithms by using one command, and the algorithm specified earlier has a higher priority. The aes-ctr-128, aes-ctr-192, aes-ctr-256, camellia-cbc-128, camellia-cbc-192, camellia-cbc-256, gmac-128, gmac-192, gmac-256, gcm-128, gcm-192, and gcm-256 encryption algorithms and the aes-xcbc-mac authentication algorithm are available only for IKEv2.
5. Specify the mode in which the security protocol encapsulates IP packets.	encapsulation-mode { transport \| tunnel }	By default, the security protocol encapsulates IP packets in tunnel mode. The transport mode applies only when the source and destination IP addresses of data flows match those of the IPsec tunnel.
6. (Optional.) Enable the Perfect Forward Secrecy (PFS) feature for the IPsec policy.	pfs { dh-group1 \| dh-group2 \| dh-group5 \| dh-group14 \| dh-group24 \| dh-group19 \| dh-group20 }	By default, the PFS feature is not used for SA negotiation. For more information about PFS, see "Configuring IKE." The security level of the Diffie-Hellman (DH) group of the initiator must be higher than or equal to that of the responder. The end without the PFS feature performs SA negotiation according to the PFS requirements of the peer end.
7. (Optional.) Enable the Extended Sequence Number (ESN) feature for the IPsec policy.	esn enable [ both ]	By default, the ESN feature is disabled.

Configuring a manual IPsec policy

In a manual IPsec policy, the parameters are configured manually, such as the keys, the SPIs, and the IP addresses of the two ends in tunnel mode.

Configuration restrictions and guidelines

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 transform sets that use the same security protocols, security algorithms, and encapsulation mode.

· The remote IPv4 address configured on the local end must be the same as the primary IPv4 address of the interface applied with the IPsec policy at the remote end. The remote IPv6 address configured on the local end must be the same as the first IPv6 address of the interface applied with the IPsec policy at the remote end.

· At each end, configure parameters for both the inbound SA and the outbound SA, and make sure the SAs in each direction are unique: For an outbound SA, make sure its triplet (remote IP address, security protocol, and SPI) is unique. For an inbound SA, make sure its SPI is unique.

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

Configuration procedure

To configure a manual IPsec policy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a manual IPsec policy entry and enter its view.	ipsec { ipv6-policy \| policy } policy-name seq-number manual	By default, no IPsec policy exists.
3. (Optional.) Configure a description for the IPsec policy.	description text	By default, no description is configured.
4. Specify an ACL for the IPsec policy.	security acl [ ipv6 ] { acl-number \| name acl-name }	By default, no ACL is specified for an IPsec policy. You can specify only one ACL for an IPsec policy.
5. Specify an IPsec transform set for the IPsec policy.	transform-set transform-set-name	By default, no IPsec transform set is specified for an IPsec policy. You can specify only one IPsec transform set for a manual IPsec policy.
6. Specify the remote IP address of the IPsec tunnel.	remote-address { ipv4-address \| ipv6 ipv6-address }	By default, the remote IP address of the IPsec tunnel is not specified. The local IPv4 address of the IPsec tunnel is the primary IPv4 address of the interface to which the IPsec policy is applied. The local IPv6 address of the IPsec tunnel is the first IPv6 address of the interface to which the IPsec policy is applied.
7. Configure an SPI for the inbound or outbound IPsec SA.	· To configure an SPI for the inbound IPsec SA: sa spi inbound { ah \| esp } spi-number · To configure an SPI for the outbound IPsec SA: sa spi outbound { ah \| esp } spi-number	By default, no SPI is configured for the inbound or outbound IPsec SA.
8. Configure keys for the IPsec SA.	· Configure an authentication key in hexadecimal format for AH: sa hex-key authentication { inbound \| outbound } ah { cipher \| simple } string · Configure an authentication key in character format for AH: sa string-key { inbound \| outbound } ah { cipher \| simple } string · Configure a key in character format for ESP: sa string-key { inbound \| outbound } esp { cipher \| simple } string · Configure an authentication key in hexadecimal format for ESP: sa hex-key authentication { inbound \| outbound } esp { cipher \| simple } string · Configure an encryption key in hexadecimal format for ESP: sa hex-key encryption { inbound \| outbound } esp { cipher \| simple } string	By default, no keys are configured for the IPsec SA. Configure keys correctly for the security protocol (AH, ESP, or both) you have specified in the IPsec transform set used by the IPsec policy. If you configure a key in both the character and the hexadecimal formats, only the most recent configuration takes effect. If you configure a key in character format for ESP, the device automatically generates an authentication key and an encryption key for ESP.

Configuring an IKE-based IPsec policy

In an IKE-based IPsec policy, the parameters are automatically negotiated through IKE.

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 using an existing IPsec policy template with the parameters to be negotiated configured.

A device using an IPsec policy that is configured in this way cannot initiate an SA negotiation, but it can respond to a negotiation request. The parameters not defined in the template are determined by the initiator. When the remote end's information (such as the IP address) is unknown, this method allows the remote end to initiate negotiations with the local end.

Configuration restrictions and guidelines

When you configure an IKE-based IPsec policy, follow these restrictions and guidelines:

· The IPsec policies at the two tunnel ends must have IPsec transform sets that use the same security protocols, security algorithms, and encapsulation mode.

· The IPsec policies at the two tunnel ends must have the same IKE profile parameters.

· An IKE-based IPsec policy can use a maximum of six IPsec transform sets. During an IKE negotiation, IKE searches for a fully matched IPsec transform set at the two ends of the IPsec tunnel. If no match is found, no SA can be set up, and the packets expecting to be protected will be dropped.

· The remote IP address of the IPsec tunnel is required on an IKE negotiation initiator and is optional on the responder. The remote IP address specified on the local end must be the same as the local IP address specified on the remote end.

· The IPsec SA uses the local lifetime settings or those proposed by the peer, whichever are smaller.

· The IPsec SA can have both a time-based lifetime and a traffic-based lifetime. The IPsec SA expires when either lifetime expires.

Directly configuring an IKE-based IPsec policy

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an IKE-based IPsec policy entry and enter its view.	ipsec { ipv6-policy \| policy } policy-name seq-number isakmp	By default, no IPsec policies exist.
3. (Optional.) Configure a description for the IPsec policy.	description text	By default, no description is configured.
4. Specify an ACL for the IPsec policy.	security acl [ ipv6 ] { acl-number \| name acl-name } [ aggregation \| per-host ]	By default, no ACL is specified for an IPsec policy. You can specify only one ACL for an IPsec policy.
5. Specify IPsec transform sets for the IPsec policy.	transform-set transform-set-name&<1-6>	By default, no IPsec transform sets are specified for an IPsec policy.
6. Specify an IKE profile for the IPsec policy.	ike-profile profile-name	By default, no IKE profile is specified for an IPsec policy, and the device selects an IKE profile configured in system view for negotiation. If no IKE profile is configured, the globally configured IKE settings are used. You can specify only one IKE profile for an IPsec policy. For more information about IKE profiles, see "Configuring IKE."
7. Specify an IKEv2 profile for the IPsec policy.	ikev2-profile profile-name	By default, no IKEv2 profile is specified for the IPsec policy. You can specify only one IKEv2 profile for an IPsec policy. For more information about IKEv2 profiles, see "Configuring IKEv2."
8. Specify the local IP address of the IPsec tunnel.	local-address { ipv4-address \| ipv6 ipv6-address }	By default, the local IPv4 address of IPsec tunnel is the primary IPv4 address of the interface to which the IPsec policy is applied, and the local IPv6 address of the IPsec tunnel is the first IPv6 address of the interface to which the IPsec policy is applied. The local IP address specified by this command must be the same as the IP address used as the local IKE identity. In a VRRP network, the local IP address must be the virtual IP address of the VRRP group to which the IPsec-applied interface belongs.
9. Specify the remote IP address of the IPsec tunnel.	remote-address { [ ipv6 ] host-name \| ipv4-address \| ipv6 ipv6-address }	By default, the remote IP address of the IPsec tunnel is not specified.
10. (Optional.) Set the IPsec SA lifetime.	sa duration { time-based seconds \| traffic-based kilobytes }	By default, the global SA lifetime is used.
11. (Optional.) Set the IPsec SA idle timeout.	sa idle-time seconds	By default, the global SA idle timeout is used.
12. (Optional.) Enables the Traffic Flow Confidentiality (TFC) padding feature.	tfc enable	By default, the TFC padding feature is disabled.
13. Return to system view.	quit	N/A
14. Set the global SA lifetime.	ipsec sa global-duration { time-based seconds \| traffic-based kilobytes }	By default, the time-based SA lifetime is 3600 seconds, and the traffic-based SA lifetime is 1843200 kilobytes.
15. (Optional.) Enable the global IPsec SA idle timeout feature, and set the global SA idle timeout.	ipsec sa idle-time seconds	By default, the global IPsec SA idle timeout feature is disabled.

Configuring an IKE-based IPsec policy by using an IPsec policy template

The configurable parameters for an IPsec policy template are the same as those when you directly configure an IKE-based IPsec policy. The difference is that more parameters are optional for an IPsec policy template. Except the IPsec transform sets and the IKE profile, all other parameters are optional.

A device using an IPsec policy that is configured by using an IPsec policy template cannot initiate an SA negotiation, but it can respond to a negotiation request. The parameters not defined in the template are determined by the initiator. For example, in an IPsec policy template, the ACL is optional. If you do not specify an ACL, the IPsec protection range has no limit. So the device accepts all ACL settings of the negotiation initiator. When the remote end's information (such as the IP address) is unknown, the IPsec policy configured by using this method allows the remote end to initiate negotiations with the local end.

To configure an IKE-based IPsec policy by using an IPsec policy template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an IPsec policy template and enter its view.	ipsec { ipv6-policy-template \| policy-template } template-name seq-number	By default, no IPsec policy templates exist.
3. (Optional.) Configure a description for the IPsec policy template.	description text	By default, no description is configured.
4. (Optional.) Specify an ACL for the IPsec policy template.	security acl [ ipv6 ] { acl-number \| name acl-name } [ aggregation \| per-host ]	By default, no ACL is specified for the IPsec policy template. You can specify only one ACL for an IPsec policy template.
5. Specify IPsec transform sets for the IPsec policy template.	transform-set transform-set-name&<1-6>	By default, no IPsec transform sets are specified for an IPsec policy template.
6. Specify an IKE profile for the IPsec policy.	ike-profile profile-name	By default, no IKE profile is specified for the IPsec policy template. You can specify only one IKE profile for an IPsec policy template and the IKE profile cannot be used by another IPsec policy template or IPsec policy. For more information about IKE profiles, see "Configuring IKE."
7. Specify an IKEv2 profile for the IPsec policy template.	ikev2-profile profile-name	By default, no IKEv2 profile is specified for the IPsec policy template. You can specify only one IKEv2 profile for an IPsec policy template. For more information about IKEv2 profiles, see "Configuring IKEv2."
8. (Optional.) Specify the local IP address of the IPsec tunnel.	local-address { ipv4-address \| ipv6 ipv6-address }	By default, the local IPv4 address of IPsec tunnel is the primary IPv4 address of the interface to which the IPsec policy is applied, and the local IPv6 address of the IPsec tunnel is the first IPv6 address of the interface to which the IPsec policy is applied. The local IP address specified by this command must be the same as the IP address used as the local IKE identity. In a VRRP network, the local IP address must be the virtual IP address of the VRRP group to which the IPsec-applied interface belongs.
9. (Optional.) Specify the remote IP address of the IPsec tunnel.	remote-address { [ ipv6 ] host-name \| ipv4-address \| ipv6 ipv6-address }	By default, the remote IP address of the IPsec tunnel is not specified.
10. (Optional.) Configure the IPsec SA lifetime.	sa duration { time-based seconds \| traffic-based kilobytes }	By default, the global SA lifetime settings are used.
11. (Optional.) Set the IPsec SA idle timeout.	sa idle-time seconds	By default, the global SA idle timeout is used.
12. (Optional.) Enables the Traffic Flow Confidentiality (TFC) padding feature.	tfc enable	By default, the TFC padding feature is disabled.
13. Return to system view.	quit	N/A
14. (Optional.) Configure the global SA lifetime.	ipsec sa global-duration { time-based seconds \| traffic-based kilobytes }	By default, time-based SA lifetime is 3600 seconds, and traffic-based SA lifetime is 1843200 kilobytes.
15. (Optional.) Enable the global IPsec SA idle timeout feature, and set the global SA idle timeout.	ipsec sa idle-time seconds	By default, the global IPsec SA idle timeout feature is disabled.
16. Create an IPsec policy by using the IPsec policy template.	ipsec { ipv6-policy \| policy } policy-name seq-number isakmp template template-name	By default, no IPsec policies exist.

Applying an IPsec policy to an interface

You can apply an IPsec policy to an interface to protect certain data flows. To cancel the IPsec protection, remove the application of the IPsec policy. In addition to physical interfaces, such as serial and Ethernet interfaces, you can apply an IPsec policy to virtual interfaces such as virtual template interfaces.

For each packet to be sent out of an interface applied with an IPsec policy, the interface looks through the IPsec policy entries in the IPsec policy in ascending order of sequence numbers. If the packet matches the ACL of an IPsec policy entry, the interface uses the IPsec policy entry to protect the packet. If no match is found, the interface sends the packet out without IPsec protection.

When the interface receives an IPsec packet destined for the local device, it searches for the inbound IPsec SA according to the SPI in the IPsec packet header for de-encapsulation. If the de-encapsulated packet matches a permit rule of the ACL, the device processes the packet. If the de-encapsulated packet does not match any permit rule of the ACL, the device drops the packet.

To apply an IPsec policy to 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. Apply an IPsec policy to the interface.	ipsec apply { policy \| ipv6-policy } policy-name	By default, no IPsec policy is applied to the interface. On an interface, you can apply a maximum of two IPsec policies: one IPv4 IPsec policy and one IPv6 IPsec policy. An IKE-based IPsec policy can be applied to multiple interfaces. As a best practice, apply an IKE-based IPsec policy to only one interface. A manual IPsec policy can be applied to only one interface.

Enabling ACL checking for de-encapsulated packets

This feature compares the de-encapsulated incoming IPsec packets against the ACL in the IPsec policy and discards those that do not match any permit rule of the ACL. This feature can protect networks against attacks using forged IPsec packets.

This feature applies only to tunnel-mode IPsec.

To enable ACL checking for de-encapsulated packets:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable ACL checking for de-encapsulated packets.	ipsec decrypt-check enable	By default, this feature is enabled.

Configuring IPsec anti-replay

IPsec anti-replay protects networks against anti-replay attacks by using a sliding window mechanism called anti-replay window. This feature 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 is not required, and the de-encapsulation process consumes large amounts of resources and degrades performance, resulting in DoS. IPsec anti-replay can check and discard replayed packets before de-encapsulation.

In some situations, service data packets are received in a different order than their original order. The IPsec anti-replay feature drops them as replayed packets, which impacts communications. If this happens, disable IPsec anti-replay checking or adjust the size of the anti-replay window as required.

IPsec anti-replay does not affect manually created IPsec SAs. According to the IPsec protocol, only IKE-based IPsec SAs support anti-replay checking.

IMPORTANT:

· IPsec anti-replay is enabled by default. Failure to detect anti-replay attacks might result in denial of services. Use caution when you disable IPsec anti-replay.

· Set the anti-replay window size as small as possible to reduce the impact on system performance.

To configure IPsec anti-replay:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable IPsec anti-replay.	ipsec anti-replay check	By default, IPsec anti-replay is enabled.
3. (Optional.) Set the size of the IPsec anti-replay window.	ipsec anti-replay window width	The default size is 64.

Configuring IPsec anti-replay redundancy

This feature synchronizes the following information from the active device to the standby device at configurable packet-based intervals:

· Lower bound values of the IPsec anti-replay window for inbound packets.

· IPsec anti-replay sequence numbers for outbound packets.

This feature, used together with IPsec redundancy, ensures uninterrupted IPsec traffic forwarding and anti-replay protection when the active device fails.

To configure IPsec anti-replay redundancy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable IPsec redundancy.	ipsec redundancy enable	By default, IPsec redundancy is disabled.
3. Enter IPsec policy view or IPsec policy template view.	· Enter IPsec policy view: ipsec { policy \| ipv6-policy } policy-name seq-number [ isakmp \| manual ] · Enter IPsec policy template view: ipsec { policy-template \| ipv6-policy-template } template-name seq-number	N/A
4. (Optional.) Set the anti-replay window synchronization interval for inbound packets and the sequence number synchronization interval for outbound packets.	redundancy replay-interval inbound inbound-interval outbound outbound-interval	By default, the active device synchronizes the anti-replay window every time it receives 1000 packets and the sequence number every time it sends 100000 packets.

Binding a source interface to an IPsec policy

For high availability, a core device is usually connected to an ISP through two links, which operate in backup or load sharing mode. The two interfaces negotiate with their peers to establish IPsec SAs respectively. When one interface fails and a link failover occurs, the other interface needs to take some time to renegotiate SAs, resulting in service interruption.

To solve these problems, bind a source interface to an IPsec policy and apply the policy to both interfaces. This enables the two physical interfaces to use the same source interface to negotiate IPsec SAs. As long as the source interface is up, the negotiated IPsec SAs will not be removed and will keep working, regardless of link failover.

Follow these guidelines when you perform this task:

· Only the IKE-based IPsec policies can be bound to a source interface.

· An IPsec policy can be bound to only one source interface.

· A source interface can be bound to multiple IPsec policies.

· If the source interface bound to an IPsec policy is removed, the IPsec policy becomes a common IPsec policy.

· If no local address is specified for an IPsec policy that has been bound to a source interface, the IPsec policy uses the IP address of the bound source interface to perform IKE negotiation. If a local address is specified, the IPsec policy uses the local address to perform IKE negotiation.

To bind a source interface to an IPsec policy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Bind a source interface to an IPsec policy.	ipsec { ipv6-policy \| policy } policy-name local-address interface-type interface-number	By default, no source interface is bound to an IPsec policy.

Enabling QoS pre-classify

CAUTION:

If you configure both IPsec and QoS on an interface, make sure the IPsec traffic classification rules match the QoS traffic 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 IPsec anti-replay is enabled, IPsec will drop the incoming packets that are out of the anti-replay window, resulting in packet loss.

If you apply both an IPsec policy and a QoS policy to an interface, QoS classifies packets by using the new headers added by IPsec. If you want QoS to classify packets by using the headers of the original IP packets, enable the QoS pre-classify feature.

IPsec traffic classification rules are determined by the rules of the specified ACL. For more information about QoS policy and classification, see ACL and QoS Configuration Guide.

To enable the QoS pre-classify feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter IPsec policy view or IPsec policy template view.	· To enter IPsec policy view: ipsec { policy \| ipv6-policy } policy-name seq-number [ isakmp \| manual ] · To enter IPsec policy template view: ipsec { policy-template \| ipv6-policy-template } template-name seq-number	N/A
3. Enable QoS pre-classify.	qos pre-classify	By default, QoS pre-classify is disabled.

Enabling logging of IPsec packets

Perform this task to enable the logging of IPsec packets that are discarded because of reasons such as IPsec SA lookup failure, AH-ESP authentication failure, and ESP encryption failure. The log information includes the source and destination IP addresses, SPI value, and sequence number of a discarded IPsec packet, and the reason for the discard.

To enable the logging of IPsec packets:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the logging of IPsec packets.	ipsec logging packet enable	By default, the logging of IPsec packets is disabled.

Configuring the DF bit of IPsec packets

Perform this task to configure the Don't Fragment (DF) bit in the new IP header of IPsec packets in one of the following ways:

· clear—Clears the DF bit in the new header.

· set—Sets the DF bit in the new header.

· copy—Copies the DF bit in the original IP header to the new IP header.

You can configure the DF bit in system view and interface view. The interface-view DF bit setting takes precedence over the system-view DF bit setting. If the interface-view DF bit setting is not configured, the interface uses the system-view DF bit setting.

Follow these guidelines when you configure the DF bit:

· The DF bit setting takes effect only in tunnel mode, and it changes the DF bit in the new IP header rather than the original IP header.

· Configure the same DF bit setting on the interfaces where the same IPsec policy bound to a source interface is applied.

· If the DF bit is set, the devices on the path cannot fragment the IPsec packets. To prevent IPsec packets from being discarded, make sure the path MTU is larger than the IPsec packet size. If you cannot make sure of this, H3C recommends you clear the DF bit.

To configure the DF bit of IPsec packets 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. Configure the DF bit of IPsec packets on the interface.	ipsec df-bit { clear \| copy \| set }	By default, the interface uses the global DF bit setting.

To configure the DF bit of IPsec packets globally:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Configure the DF bit of IPsec packets globally.	ipsec global-df-bit { clear \| copy \| set }	By default, IPsec copies the DF bit in the original IP header to the new IP header.

Configuring IPsec RRI

Configuration guidelines

When you enable or disable IPsec RRI for an IPsec policy, the device deletes all IPsec SAs created by this IPsec policy, and the associated static routes.

If you change the preference value or tag value for an IPsec policy, the device deletes all IPsec SAs created by this IPsec policy, and the associated static routes. Your change takes effect for future IPsec RRI-created static routes.

You can set preferences for the static routes created by IPsec RRI to flexibly apply route management policies. For example, you can set the same preference for multiple routes to the same destination to implement load sharing, or you can set different preferences to implement route backup.

You can also set tags for the static routes created by IPsec RRI to implement flexible route control through routing policies.

IPsec RRI does not generate a static route to a destination address to be protected if the destination address is not defined in the ACL used by an IPsec policy or an IPsec policy template. You must manually configure a static route to the destination address.

Configuration procedure

To configure IPsec RRI:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter IPsec policy view or IPsec policy template view.	· To enter IPsec policy view: ipsec { policy \| ipv6-policy } policy-name seq-number isakmp · To enter IPsec policy template view: ipsec { policy-template \| ipv6-policy-template } template-name seq-number	N/A
3. Enable IPsec RRI.	reverse-route dynamic	By default, IPsec RRI is disabled. IPsec RRI is supported in both tunnel mode and transport mode.
4. Optional.) Set the preference value for the static routes created by IPsec RRI.	reverse-route preference number	The default value is 60.
5. (Optional.) Set the tag value for the static routes created by IPsec RRI.	reverse-route tag tag-value	The default value is 0.

Configuring SNMP notifications for IPsec

After you enable SNMP notifications for IPsec, the IPsec module notifies the NMS of important module events. The notifications are sent to the device's SNMP module. You can configure the notification transmission parameters for the SNMP module to specify how the SNMP module displays notifications. For more information about SNMP notifications, see Network Management and Monitoring Configuration Guide.

To generate and output SNMP notifications for a specific IPsec failure or event type, perform the following tasks:

1. Enable SNMP notifications for IPsec globally.

2. Enable SNMP notifications for the failure or event type.

To configure SNMP notifications for IPsec:

Step	Command	Remarks
1. Enter system view	system-view	N/A
2. Enable SNMP notifications for IPsec globally.	snmp-agent trap enable ipsec global	By default, SNMP notifications for IPsec are disabled.
3. Enable SNMP notifications for the specified failure or event types.	snmp-agent trap enable ipsec [ auth-failure \| decrypt-failure \| encrypt-failure \| invalid-sa-failure \| no-sa-failure \| policy-add \| policy-attach \| policy-delete \| policy-detach \| tunnel-start \| tunnel-stop ] *	By default, SNMP notifications for all failure and event types are disabled.

Configuring IPsec fragmentation

Perform this task to configure the device to fragment packets before or after IPsec encapsulation.

If you configure the device to fragment packets before IPsec encapsulation, the device predetermines the encapsulated packet size before the actual encapsulation. If the encapsulated packet size exceeds the MTU of the output interface, the device fragments the packets before encapsulation. If a packet's DF bit is set, the device drops the packet and sends an ICMP error message.

If you configure the device to fragment packets after IPsec encapsulation, the device directly encapsulates the packets and fragments the encapsulated packets in subsequent service modules.

This feature takes effect on IPsec-protected IPv4 packets.

To configure IPsec fragmentation:

Step	Command	Remarks
1. Enter system view	system-view	N/A
2. Configure IPsec fragmentation.	ipsec fragmentation { after-encryption \| before-encryption }	By default, the device fragments packets before IPsec encapsulation.

Setting the maximum number of IPsec tunnels

To maximize concurrent performance of IPsec when memory is sufficient, increase the maximum number of IPsec tunnels. To ensure service availability when memory is insufficient, decrease the maximum number of IPsec tunnels.

To set the maximum number of IPsec tunnels:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the maximum number of IPsec tunnels.	ipsec limit max-tunnel tunnel-limit	By default, the number of IPsec tunnels is not limited.

Enabling logging for IPsec negotiation

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable logging for IPsec negotitation.	ipsec logging negotiation enable	By default, logging for IPsec negotitation is disabled.

Displaying and maintaining IPsec

Execute display commands in any view and reset commands in user view.

Task	Command
Display IPsec policy information.	display ipsec { ipv6-policy \| policy } [ policy-name [ seq-number ] ]
Display IPsec policy template information.	display ipsec { ipv6-policy-template \| policy-template } [ template-name [ seq-number ] ]
Display IPsec transform set information.	display ipsec transform-set [ transform-set-name ]
Display IPsec SA information.	display ipsec sa [ brief \| count \| interface interface-type interface-number \| { ipv6-policy \| policy } policy-name [ seq-number ] \| remote [ ipv6 ] ip-address ]
Display IPsec statistics.	display ipsec statistics [ tunnel-id tunnel-id ]
Display IPsec tunnel information.	display ipsec tunnel { brief \| count \| tunnel-id tunnel-id }
Clear IPsec SAs.	reset ipsec sa [ { ipv6-policy \| policy } policy-name [ seq-number ] \| remote { ipv4-address \| ipv6 ipv6-address } \| spi { ipv4-address \| ipv6 ipv6-address } { ah \| esp } spi-num ]
Clear IPsec statistics.	reset ipsec statistics [ tunnel-id tunnel-id ]

Configuring IKE

Unless otherwise specified, the term "IKE" in this chapter refers to IKEv1.

Overview

Built on a framework defined by ISAKMP, Internet Key Exchange (IKE) provides automatic key negotiation and SA establishment services for IPsec.

IKE provides the following benefits for IPsec:

· Automatically negotiates IPsec parameters.

· Performs DH exchanges to calculate shared keys, making sure each SA has a key that is independent of other keys.

· Automatically negotiates SAs when the sequence number in the AH or ESP header overflows, making sure IPsec can provide the anti-replay service by using the sequence number.

As shown in Figure 95, IKE negotiates SAs for IPsec and transfers the SAs to IPsec, and IPsec uses the SAs to protect IP packets.

Figure 95 Relationship between IKE and IPsec

IKE negotiation process

IKE negotiates keys and SAs for IPsec in two phases:

1. Phase 1—The two peers establish an IKE SA, a secure, authenticated channel for communication. In this phase, two modes are available: main mode and aggressive mode.

2. Phase 2—Using the IKE SA established in phase 1, the two peers negotiate to establish IPsec SAs.

Figure 96 IKE exchange process in main mode

As shown in Figure 96, the main mode of IKE negotiation in phase 1 involves three pairs of messages:

· SA exchange—Used for negotiating the IKE security policy.

· Key exchange—Used for exchanging the DH public value and other values, such as the random number. The two peers use the exchanged data to generate key data and use the encryption key and authentication key to ensure the security of IP packets.

· ID and authentication data exchange—Used for identity authentication.

The main difference between the main mode and the aggressive mode is that the aggressive mode does not provide identity information protection and exchanges only three messages, rather than three pairs. The main mode provides identity information protection but is slower.

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.

Identity authentication

The IKE identity authentication mechanism is used to authenticate the identity of the communicating peers. The device supports the following identity authentication methods:

· Pre-shared key authentication—Two communicating peers use the pre-configured shared key for identity authentication.

· RSA signature authentication and DSA signature authentication—Two communicating peers use the digital certificates issued by the CA for identity authentication.

The pre-shared key authentication method does not require certificates and is easy to configure. It is usually deployed in small networks.

The signature authentication methods provide higher security and are usually deployed in networks with the headquarters and some branches. When deployed in a network with many branches, a signature authentication method can simplify the configuration because only one PKI domain is required. If you use the pre-shared key authentication method, you must configure a pre-shared key for each branch on the Headquarters node.

DH algorithm

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.

PFS

The Perfect Forward Secrecy (PFS) feature is a security feature based on the DH algorithm. After PFS is enabled, an additional DH exchange is performed in IKE phase 2 to make sure IPsec keys have no derivative relations with IKE keys and a broken key brings no threats to other keys.

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

· Internet Draft, draft-ietf-ipsec-isakmp-xauth-06

· Internet Draft, draft-dukes-ike-mode-cfg-02

IKE configuration prerequisites

Determine the following parameters prior to IKE configuration:

· The algorithms to be used during IKE negotiation, including the identity authentication method, encryption algorithm, authentication algorithm, and DH group.

? Different algorithms provide different levels of protection. A stronger algorithm provides more resistance to decryption but uses more resources.

? A DH group that uses more bits provides higher security but needs more time for processing.

· The pre-shared key or PKI domain for IKE negotiation. For more information about PKI, see "Configuring PKI."

· The IKE-based IPsec policies for the communicating peers. If you do not specify an IKE profile in an IPsec policy, the device selects an IKE profile for the IPsec policy. If no IKE profile is configured, the globally configured IKE settings are used. For more information about IPsec, see "Configuring IPsec."

Feature and hardware compatibility

Hardware series	Model	IKE compatibility
WX1800H series	WX1804H	Yes
	WX1810H	Yes
	WX1820H	Yes
	WX1840H	No
WX3800H series	WX3820H WX3840H	No
WX5800H series	WX5860H	No

IKE configuration task list

Tasks at a glance	Remarks
(Optional.) Configuring an IKE profile	N/A
(Optional.) Configuring an IKE proposal	Required when you specify IKE proposals for the IKE profile.
(Optional.) Configuring an IKE keychain	Required when pre-shared authentication is used in IKE negotiation phase 1.
(Optional.) Configuring the global identity information	N/A
(Optional.) Configuring the IKE keepalive feature	N/A
(Optional.) Configuring the IKE NAT keepalive feature	N/A
(Optional.) Configuring IKE DPD	N/A
(Optional.) Enabling invalid SPI recovery	N/A
(Optional.) Setting the maximum number of IKE SAs	N/A
(Optional.) Configuring an IKE IPv4 address pool	N/A
(Optional.) Configuring SNMP notifications for IKE	N/A
(Optional.) Enabling logging for IKE negotitation	N/A

Configuring an IKE profile

An IKE profile is intended to provide a set of parameters for IKE negotiation. To configure an IKE profile, perform the following tasks:

1. Configure peer IDs. When an end needs to select an IKE profile, it compares the received peer ID with the peer IDs of its local IKE profiles. If a match is found, it uses the IKE profile with the matching peer ID for IKE negotiation.

2. Configure the IKE keychain or PKI domain for the IKE proposals to use:

? To use digital signature authentication, configure a PKI domain.

? To use pre-shared key authentication, configure an IKE keychain.

3. Specify the negotiation mode (main or aggressive) that the device uses as the initiator. When the device acts as the responder, it uses the IKE negotiation mode of the initiator.

4. Specify the IKE proposals that the device can use as the initiator. An IKE proposal specified earlier has a higher priority. When the device acts as the responder, it uses the IKE proposals configured in system view to match the IKE proposals received from the initiator. If a match is not found, the negotiation fails.

5. Configure the local ID, the ID that the device uses to identify itself to the peer during IKE negotiation:

? For digital signature authentication, the device can use an ID of any type. If the local ID is an IP address that is different from the IP address in the local certificate, the device uses the FQDN (the device name configured by using the sysname command) instead.

? For pre-shared key authentication, the device can use an ID of any type other than the DN.

6. Configure IKE DPD to detect dead IKE peers. You can also configure this feature in system view. The IKE DPD settings configured in the IKE profile view takes precedence over those configured in system view.

7. Specify a local interface or IP address for the IKE profile so the profile can be applied only to the specified interface or IP address. For this task, specify the local address configured in IPsec policy or IPsec policy template view (using the local-address command). If no local address is configured, specify the IP address of the interface that uses the IPsec policy.

8. Specify a priority number for the IKE profile. To determine the priority of an IKE profile:

a. First, the device examines the existence of the match local address command. An IKE profile with the match local address command configured has a higher priority.

b. If a tie exists, the device compares the priority numbers. An IKE profile with a smaller priority number has a higher priority.

c. If a tie still exists, the device prefers an IKE profile configured earlier.

9. Enable client authentication.

Client authentication provides extended (XAUTH) authentication in IKE negotiation for secure remote access to an IPsec VPN.

When networking an IPsec VPN for remote access, you can enable client authentication on the IPsec gateway. After the IKE phase-1 negotiation, the IPsec gateway uses AAA to perform client authentication on remote users. Remote users that provide the correct username and password pass the authentication and continue with the negotiation. AAA configuration is also required on the IPsec gateway for client authentication. For more information about AAA, see "Configuring AAA."

10. Enable AAA authorization.

The AAA authorization feature enables IKE to request authorization attributes, such as the IKE IPv4 address pool, from AAA. IKE uses the address pool to assign IPv4 addresses to remote users. For more information about AAA authorization, see "Configuring AAA."

To configure an IKE profile:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an IKE profile and enter its view.	ike profile profile-name	By default, no IKE profile is configured.
3. Configure a peer ID.	match remote { certificate policy-name \| identity { address { { ipv4-address [ mask \| mask-length ] \| range low-ipv4-address high-ipv4-address } \| ipv6 { ipv6-address [ prefix-length ] \| range low-ipv6-address high-ipv6-address } } \| fqdn fqdn-name \| user-fqdn user-fqdn-name } }	By default, an IKE profile has no peer ID. Each of the two peers must have at least one peer ID configured.
4. Specify the keychain for pre-shared key authentication or the PKI domain used to request a certificate for digital signature authentication.	· To specify the keychain for pre-shared key authentication: keychain keychain-name · To specify the PKI domain used to request a certificate for digital signature authentication: certificate domain domain-name	Configure at least one command as required. By default, no IKE keychain or PKI domain is specified for an IKE profile.
5. Specify the IKE negotiation mode for phase 1.	exchange-mode { aggressive \| main }	By default, the main mode is used during IKE negotiation phase 1.
6. Specify IKE proposals for the IKE profile.	proposal proposal-number&<1-6>	By default, no IKE proposals are specified for an IKE profile and the IKE proposals configured in system view are used for IKE negotiation.
7. Configure the local ID.	local-identity { address { ipv4-address \| ipv6 ipv6-address } \| dn \| fqdn [ fqdn-name ] \| user-fqdn [ user-fqdn-name ] }	By default, no local ID is configured for an IKE profile, and an IKE profile uses the local ID configured in system view. If the local ID is not configured in system view, the IKE profile uses the IP address of the interface to which the IPsec policy or IPsec policy template is applied as the local ID.
8. (Optional.) Configure IKE DPD.	dpd interval interval [ retry seconds ] { on-demand \| periodic }	By default, IKE DPD is not configured for an IKE profile and an IKE profile uses the DPD settings configured in system view. If IKE DPD is not configured in system view either, the device does not perform dead IKE peer detection.
9. (Optional.) Specify the local interface or IP address to which the IKE profile can be applied.	match local address { interface-type interface-number \| { ipv4-address \| ipv6 ipv6-address } }	By default, an IKE profile can be applied to any local interface or IP address.
10. (Optional.) Specify a priority for the IKE profile.	priority priority	By default, the priority of an IKE profile is 100.
11. (Optional.) Enable client authentication.	client authentication xauth	By default, client authentication is disabled.
12. (Optional.) Enable AAA authorization.	aaa authorization domain domain-name username user-name	By default, AAA authorization is disabled.

Configuring an IKE proposal

An IKE proposal defines a set of attributes describing how IKE negotiation in phase 1 should take place. You can create multiple IKE proposals with different priorities. The priority of an IKE proposal is represented by its sequence number. The lower the sequence number, the higher the priority.

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.

? If the initiator is using an IPsec policy with an IKE profile, the initiator sends all IKE proposals specified in the IKE profile to the peer. An IKE proposal specified earlier for the IKE profile has a higher priority.

? If the initiator is using an IPsec policy with no IKE profile, the initiator sends all its IKE proposals to the peer. An IKE proposal with a smaller number has a higher priority.

· The peer searches its own IKE proposals for a match. The search starts from the IKE proposal with the highest priority and proceeds in descending order of priority until a match is found. The matching IKE proposals are used to establish the IKE SA. If all user-defined IKE proposals are found mismatching, the two peers use their default IKE proposals to establish the IKE SA.

Two matching IKE proposals have the same encryption algorithm, authentication method, authentication algorithm, and DH group. The SA lifetime takes the smaller one of the two proposals' SA lifetime settings.

To configure an IKE proposal:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an IKE proposal and enter its view.	ike proposal proposal-number	By default, there is an IKE proposal that is used as the default IKE proposal.
3. Configure a description for the IKE proposal.	description	By default, an IKE proposal does not have a description.
4. Specify an encryption algorithm for the IKE proposal.	encryption-algorithm { 3des-cbc \| aes-cbc-128 \| aes-cbc-192 \| aes-cbc-256 \| des-cbc }	By default, an IKE proposal uses the 56-bit DES encryption algorithm in CBC mode.
5. Specify an authentication method for the IKE proposal.	authentication-method { dsa-signature \| pre-share \| rsa-signature }	By default, an IKE proposal uses the pre-shared key authentication method.
6. Specify an authentication algorithm for the IKE proposal.	authentication-algorithm { md5 \| sha \| sha256 \| sha384 \| sha512 }	By default, an IKE proposal uses the HMAC-SHA1 authentication algorithm.
7. Specify a DH group for key negotiation in phase 1.	dh { group1 \| group14 \| group2 \| group24 \| group5 }	By default, DH group 1 (the 768-bit DH group) is used.
8. Set the IKE SA lifetime for the IKE proposal.	sa duration seconds	By default, the IKE SA lifetime is 86400 seconds.

Configuring an IKE keychain

Perform this task when you configure the IKE to use the pre-shared key for authentication.

Follow these guidelines when you configure an IKE keychain:

1. Two peers must be configured with the same pre-shared key to pass pre-shared key authentication.

2. You can specify the local address configured in IPsec policy or IPsec policy template view (using the local-address command) for the IKE keychain to be applied. If no local address is configured, specify the IP address of the interface that uses the IPsec policy.

3. You can specify a priority number for the IKE keychain. To determine the priority of an IKE keychain:

a. The device examines the existence of the match local address command. An IKE keychain with the match local address command configured has a higher priority.

b. If a tie exists, the device compares the priority numbers. An IKE keychain with a smaller priority number has a higher priority.

c. If a tie still exists, the device prefers an IKE keychain configured earlier.

To configure the IKE keychain:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an IKE keychain and enter its view.	ike keychain keychain-name	By default, no IKE keychain exists.
3. Configure a pre-shared key.	pre-shared-key { address { ipv4-address [ mask \| mask-length ] \| ipv6 ipv6-address [ prefix-length ] } \| hostname host-name } key { cipher cipher-key \| simple simple-key }	By default, no pre-shared key is configured. For security purposes, all pre-shared keys, including those configured in plain text, are saved in cipher text to the configuration file.
4. (Optional.) Specify a local interface or IP address to which the IKE keychain can be applied.	match local address { interface-type interface-number \| { ipv4-address \| ipv6 ipv6-address } }	By default, an IKE keychain can be applied to any local interface or IP address.
5. (Optional.) Specify a priority for the IKE keychain.	priority priority	The default priority is 100.

Configuring the global identity information

Follow these guidelines when you configure the global identity information for the local IKE:

· The global identity can be used by the device for all IKE SA negotiations, and the local identity (set by the local-identity command) can be used only by the device that uses the IKE profile.

· When signature authentication is used, you can set any type of the identity information.

· When pre-shared key authentication is used, you cannot set the DN as the identity.

To configure the global identity information:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Configure the global identity to be used by the local end.	ike identity { address { ipv4-address \| ipv6 ipv6-address } \| dn \| fqdn [ fqdn-name ] \| user-fqdn [ user-fqdn-name ] }	By default, the IP address of the interface to which the IPsec policy or IPsec policy template is applied is used as the IKE identity.
3. (Optional.) Configure the local device to always obtain the identity information from the local certificate for signature authentication.	ike signature-identity from-certificate	By default, the local end uses the identity information specified by local-identity or ike identity for signature authentication. Configure this command on the local device when the following conditions exist: · If the aggressive IKE SA negotiation mode and signature authentication are used. · When the device interconnects with a peer device that runs a Comware V5-based release supporting only DN for signature authentication.

Configuring the IKE keepalive feature

IKE sends keepalive packets to query the liveness of the peer. If the peer is configured with the keepalive timeout time, you must configure the keepalive interval on the local device. If the peer receives no keepalive packets during the timeout time, the IKE SA is deleted along with the IPsec SAs it negotiated.

Follow these guidelines when you configure the IKE keepalive feature:

· Configure IKE DPD instead of IKE keepalive unless IKE DPD is not supported on the peer. The IKE keepalive feature sends keepalives at regular intervals, which consumes network bandwidth and resources.

· The keepalive timeout time configured on the local device must be longer than the keepalive interval configured at the peer. Since it seldom occurs that more than three consecutive packets are lost on a network, you can set the keepalive timeout three times as long as the keepalive interval.

To configure the IKE keepalive feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the IKE SA keepalive interval.	ike keepalive interval interval	By default, no keepalives are sent to the peer.
3. Set the IKE SA keepalive timeout time.	ike keepalive timeout seconds	By default, IKE SA keepalive never times out.

Configuring the IKE NAT keepalive feature

If IPsec traffic passes through a NAT device, you must configure the NAT traversal feature. If no packet travels across an IPsec tunnel in a period of time, the NAT sessions are aged and deleted, disabling the tunnel from transmitting data to the intended end. To prevent NAT sessions from being aged, configure the NAT keepalive feature on the IKE gateway behind the NAT device to send NAT keepalive packets to its peer periodically to keep the NAT session alive.

To configure the IKE NAT keepalive feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the IKE NAT keepalive interval.	ike nat-keepalive seconds	The default interval is 20 seconds.

Configuring IKE DPD

DPD detects dead peers. It can operate in periodic mode or on-demand mode.

· Periodic DPD—Sends a DPD message at regular intervals. It features an earlier detection of dead peers, but consumes more bandwidth and CPU.

· On-demand DPD—Sends a DPD message based on traffic. When the device has traffic to send and is not aware of the liveness of the peer, it sends a DPD message to query the status of the peer. If the device has no traffic to send, it never sends DPD messages. This mode is recommended.

The IKE DPD works as follows:

1. The local device sends a DPD message to the peer, and waits for a response from the peer.

2. If the peer does not respond within the retry interval specified by the retry seconds parameter, the local device resends the message.

3. If still no response is received within the retry interval, the local end sends the DPD message again. The system allows a maximum of two retries.

4. If the local device receives no response after two retries, the device considers the peer to be dead, and deletes the IKE SA along with the IPsec SAs it negotiated.

5. If the local device receives a response from the peer during the detection process, the peer is considered alive. The local device performs a DPD detection again when the triggering interval is reached or it has traffic to send, depending on the DPD mode.

Follow these guidelines when you configure the IKE DPD feature:

· When DPD settings are configured in both IKE profile view and system view, the DPD settings in IKE profile view apply. If DPD is not configured in IKE profile view, the DPD settings in system view apply.

· It is a good practice to set the triggering interval longer than the retry interval so that a DPD detection is not triggered during a DPD retry.

To configure IKE DPD:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable sending IKE DPD messages.	ike dpd interval interval [ retry seconds ] { on-demand \| periodic }	By default, IKE DPD is disabled.

Enabling invalid SPI recovery

An IPsec "black hole" occurs when one IPsec peer fails (for example, a peer can fail if a reboot occurs). One peer fails and loses its SAs with the other peer. When an IPsec peer receives a data packet for which it cannot find an SA, an invalid SPI is encountered. The peer drops the data packet and tries to send an SPI invalid notification to the data originator. This notification is sent by using the IKE SA. Because no IKE SA is available, the notification is not sent. The originating peer continues sending the data by using the IPsec SA that has the invalid SPI, and the receiving peer keeps dropping the traffic.

The invalid SPI recovery feature enables the receiving peer to set up an IKE SA with the originator so that an SPI invalid notification can be sent. Upon receiving the notification, the originating peer deletes the IPsec SA that has the invalid SPI. If the originator has data to send, new SAs will be set up.

Use caution when you enable the invalid SPI recovery feature because using this feature can result in a DoS attack. Attackers can make a great number of invalid SPI notifications to the same peer.

To enable invalid SPI recovery:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable invalid SPI recovery.	ike invalid-spi-recovery enable	By default, the invalid SPI recovery is disabled.

Setting the maximum number of IKE SAs

You can set the maximum number of half-open IKE SAs and the maximum number of established IKE SAs.

· The supported maximum number of half-open IKE SAs depends on the device's processing capability. Adjust the maximum number of half-open IKE SAs to make full use of the device's processing capability without affecting the IKE SA negotiation efficiency.

· The supported maximum number of established IKE SAs depends on the device's memory space. Adjust the maximum number of established IKE SAs to make full use of the device's memory space without affecting other applications in the system.

To set the limit on the number of IKE SAs:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the maximum number of half-open IKE SAs and the maximum number of established IKE SAs.	ike limit { max-negotiating-sa negotiation-limit \| max-sa sa-limit }	By default, there is no limit to the maximum number of IKE SAs.

Configuring an IKE IPv4 address pool

To perform centralized management on remote users, an IPsec gateway can use an IPv4 address pool to assign private IPv4 addresses to remote users.

You must use an IKE IPv4 address pool together with AAA authorization by specifying the IKE IPv4 address pool as an AAA authorization attribute. For more information about AAA authorization, see "Configuring AAA."

To configure an IKE IPv4 address pool:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Configure an IKE IPv4 address pool.	ike address-group group-name start-ipv4-address end-ipv4-address [ mask \| mask-length ]	By default, no IKE IPv4 address pool exists.

Configuring SNMP notifications for IKE

After you enable SNMP notifications for IKE, the IKE module notifies the NMS of important module events. The notifications are sent to the device's SNMP module. You can configure the notification transmission parameters for the SNMP module to specify how the SNMP module displays notifications. For more information about SNMP notifications, see Network Management and Monitoring Configuration Guide.

To generate and output SNMP notifications for a specific IKE failure or event type, perform the following tasks:

1. Enable SNMP notifications for IKE globally.

2. Enable SNMP notifications for the failure or event type.

To configure SNMP notifications for IKE:

Step	Command	Remarks
1. Enter system view	system-view	N/A
2. Enable SNMP notifications for IKE globally.	snmp-agent trap enable ike global	By default, SNMP notifications for IKE are enabled.
3. Enable SNMP notifications for the specified failure or event types.	snmp-agent trap enable ike [ attr-not-support \| auth-failure \| cert-type-unsupport \| cert-unavailable \| decrypt-failure \| encrypt-failure \| invalid-cert-auth \| invalid-cookie \| invalid-id \| invalid-proposal \| invalid-protocol \| invalid-sign \| no-sa-failure \| proposal-add \| proposal–delete \| tunnel-start \| tunnel-stop \| unsupport-exch-type ] *	By default, SNMP notifications for all failure and event types are enabled.

Enabling logging for IKE negotitation

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable logging for IKE negotitation.	ike logging negotiation enable	By default, logging for IKE negotitation is disabled.

Displaying and maintaining IKE

Execute display commands in any view and reset commands in user view.

Task	Command
Display configuration information about all IKE proposals.	display ike proposal
Display information about the current IKE SAs.	display ike sa [ verbose [ connection-id connection-id \| remote-address [ ipv6 ] remote-address ] ]
Display IKE statistics.	display ike statistics
Delete IKE SAs.	reset ike sa [ connection-id connection-id ]
Clear IKE MIB statistics.	reset ike statistics

Troubleshooting IKE

IKE negotiation failed because no matching IKE proposals were found

Symptom

1. The IKE SA is in Unknown state.

<Sysname> display ike sa

Connection-ID Remote Flag DOI

------------------------------------------------------------------

1 192.168.222.5 Unknown IPSEC

Flags:

RD--READY RL--REPLACED FD-FADING

2. When IKE event debugging and packet debugging are enabled, the following messages appear:

IKE event debugging message:

The attributes are unacceptable.

IKE packet debugging message:

Construct notification packet: NO_PROPOSAL_CHOSEN.

Analysis

Certain IKE proposal settings are incorrect.

Solution

1. Examine the IKE proposal configuration to see whether the two ends have matching IKE proposals.

2. Modify the IKE proposal configuration to make sure the two ends have matching IKE proposals.

IKE negotiation failed because no IKE proposals or IKE keychains are specified correctly

Symptom

1. The IKE SA is in Unknown state.

<Sysname> display ike sa

Connection-ID Remote Flag DOI

------------------------------------------------------------------

1 192.168.222.5 Unknown IPSEC

Flags:

RD--READY RL--REPLACED FD-FADING

2. The following IKE event debugging or packet debugging message appeared:

IKE event debugging message:

Notification PAYLOAD_MALFORMED is received.

IKE packet debugging message:

Construct notification packet: PAYLOAD_MALFORMED.

Analysis

· If the following debugging information appeared, the matched IKE profile is not using the matched IKE proposal:

Failed to find proposal 1 in profile profile1.

· If the following debugging information appeared, the matched IKE profile is not using the matched IKE keychain:

Failed to find keychain keychain1 in profile profile1.

Solution

· Verify that the matched IKE proposal (IKE proposal 1 in this debugging message example) is specified for the IKE profile (IKE profile 1 in the example).

· Verify that the matched IKE keychain (IKE keychain 1 in this debugging message example) is specified for the IKE profile (IKE profile 1 in the example).

IPsec SA negotiation failed because no matching IPsec transform sets were found

Symptom

1. The display ike sa command shows that the IKE SA negotiation succeeded and the IKE SA is in RD state, but the display ipsec sa command shows that the expected IPsec SA has not been negotiated yet.

2. The following IKE debugging message appeared:

The attributes are unacceptable.

Or:

Construct notification packet: NO_PROPOSAL_CHOSEN.

Analysis

Certain IPsec policy settings are incorrect.

Solution

1. Examine the IPsec configuration to see whether the two ends have matching IPsec transform sets.

2. Modify the IPsec configuration to make sure the two ends have matching IPsec transform sets.

IPsec SA negotiation failed due to invalid identity information

Symptom

1. The display ike sa command shows that the IKE SA negotiation succeeded and the IKE SA is in RD state, but the display ipsec sa command shows that the expected IPsec SA has not been negotiated yet.

2. The following IKE debugging message appeared:

Notification INVALID_ID_INFORMATION is received.

Or:

Failed to get IPsec policy when renegotiating IPsec SA. Delete IPsec SA.

Construct notification packet: INVALID_ID_INFORMATION.

Analysis

Certain IPsec policy settings of the responder are incorrect. Verify the settings as follows:

1. Use the display ike sa verbose command to verify that matching IKE profiles were found in IKE negotiation phase 1. If no matching IKE profiles were found and the IPsec policy is using an IKE profile, the IPsec SA negotiation fails.

# Verify that matching IKE profiles were found in IKE negotiation phase 1.

<Sysname> display ike sa verbose

-----------------------------------------------

Connection ID: 3

Outside VPN:

Inside VPN:

Profile:

Transmitting entity: Responder

-----------------------------------------------

Local IP: 192.168.222.5

Local ID type: IPV4_ADDR

Local ID: 192.168.222.5

Remote IP: 192.168.222.71

Remote ID type: IPV4_ADDR

Remote ID: 192.168.222.71

Authentication-method: PRE-SHARED-KEY

Authentication-algorithm: MD5

Encryption-algorithm: 3DES-CBC

Life duration(sec): 86400

Remaining key duration(sec): 85847

Exchange-mode: Main

Diffie-Hellman group: Group 1

NAT traversal: Not detected

# Verify that the IPsec policy is using an IKE profile.

[Sysname] display ipsec policy

-------------------------------------------

IPsec Policy: policy1

Interface: Vlan-interface100

-------------------------------------------

-----------------------------

Sequence number: 1

Mode: ISAKMP

-----------------------------

Security data flow: 3000

Selector mode: aggregation

Local address: 192.168.222.5

Remote address: 192.168.222.71

Transform set: transform1

IKE profile: profile1

SA duration(time based):

SA duration(traffic based):

SA idle time:

2. Verify that the ACL specified for the IPsec policy is correctly configured. If the flow range defined by the responder's ACL is smaller than that defined by the initiator's ACL, IPsec proposal matching will fail.

For example, if the initiator's ACL defines a flow from one network segment to another but the responder's ACL defines a flow from one host to another host, IPsec proposal matching will fail.

# On the initiator:

[Sysname] display acl 3000

Advanced IPv4 ACL 3000, 1 rules,

ACL's step is 5

rule 0 permit ip source 192.168.222.0 0.0.0.255 destination 192.168.222.0 0.0.0.255

# On the responder:

[Sysname] display acl 3000

Advanced IPv4 ACL 3000, 1 rules,

ACL's step is 5

rule 0 permit ip source 192.168.222.71 0 destination 192.168.222.5 0

3. Verify that the IPsec policy has a remote address and an IPsec transform set configured and that the IPsec transform set has all necessary settings configured.

If, for example, the IPsec policy has no remote address configured, the IPsec SA negotiation will fail:

[Sysname] display ipsec policy

-------------------------------------------

IPsec Policy: policy1

Interface: Vlan-interface100

-------------------------------------------

-----------------------------

Sequence number: 1

Mode: ISAKMP

-----------------------------

Security data flow: 3000

Selector mode: aggregation

Local address: 192.168.222.5

Remote address:

Transform set: transform1

IKE profile: profile1

SA duration(time based):

SA duration(traffic based):

SA idle time:

Solution

1. If the IPsec policy specifies an IKE profile but no matching IKE profile was found in IKE negotiation, perform one of the following tasks on the responder:

? Remove the specified IKE profile from the IPsec policy.

? Modify the specified IKE profile to match the IKE profile of the initiator.

2. If the flow range defined by the responder's ACL is smaller than that defined by the initiator's ACL, modify the responder's ACL so the ACL defines a flow range equal to or greater than that of the initiator's ACL.

For example:

[Sysname] display acl 3000

Advanced IPv4 ACL 3000, 2 rules,

ACL's step is 5

rule 0 permit ip source 192.168.222.0 0.0.0.255 destination 192.168.222.0 0.0.0.255

3. Configure the missing settings (for example, the remote address).

Configuring IKEv2

Overview

Internet Key Exchange version 2 (IKEv2) is an enhanced version of IKEv1. The same as IKEv1, IKEv2 has a set of self-protection mechanisms and can be used on insecure networks for reliable identity authentication, key distribution, and IPsec SA negotiation. IKEv2 provides stronger protection against attacks and higher key exchange ability and needs less message exchanges than IKEv1.

IKEv2 negotiation process

Compared with IKEv1, IKEv2 simplifies the negotiation process and is much more efficient.

IKEv2 defines three types of exchanges: initial exchanges, CREATE_CHILD_SA exchange, and INFORMATIONAL exchange.

As shown in Figure 97, IKEv2 uses two exchanges during the initial exchange process: IKE_SA_INIT and IKE_AUTH, each with two messages.

· IKE_SA_INIT exchange—Negotiates IKE SA parameters and exchanges keys.

· IKE_AUTH exchange—Authenticates the identity of the peer and establishes IPsec SAs.

After the four-message initial exchanges, IKEv2 sets up one IKE SA and one pair of IPsec SAs. For IKEv1 to set up one IKE SA and one pair of IPsec SAs, it must go through two phases that use a minimum of six messages.

To set up one more pair of IPsec SAs within the IKE SA, IKEv2 goes on to perform an additional two-message exchange—the CREATE_CHILD_SA exchange. One CREATE_CHILD_SA exchange creates one pair of IPsec SAs. IKEv2 also uses the CREATE_CHILD_SA exchange to rekey IKE SAs and Child SAs.

IKEv2 uses the INFORMATIONAL exchange to convey control messages about errors and notifications.

Figure 97 IKEv2 Initial exchange process

New features in IKEv2

DH guessing

In the IKE_SA_INIT exchange, the initiator guesses the DH group that the responder is most likely to use and sends it in an IKE_SA_INIT request message. If the initiator's guess is correct, the responder responds with an IKE_SA_INIT response message and the IKE_SA_INIT exchange is finished. If the guess is wrong, the responder responds with an INVALID_KE_PAYLOAD message that contains the DH group that it wants to use. The initiator then uses the DH group selected by the responder to reinitiate the IKE_SA_INIT exchange. The DH guessing mechanism allows for more flexible DH group configuration and enables the initiator to adapt to different responders.

Cookie challenging

Messages for the IKE_SA_INIT exchange are in plain text. An IKEv1 responder cannot confirm the validity of the initiators and must maintain half-open IKE SAs, which makes the responder susceptible to DoS attacks. An attacker can send a large number of IKE_SA_INIT requests with forged source IP addresses to the responder, exhausting the responder's system resources.

IKEv2 introduces the cookie challenging mechanism to prevent such DoS attacks. When an IKEv2 responder maintains a threshold number of half-open IKE SAs, it starts the cookie challenging mechanism. The responder generates a cookie and includes it in the response sent to the initiator. If the initiator initiates a new IKE_SA_INIT request that carries the correct cookie, the responder considers the initiator valid and proceeds with the negotiation. If the carried cookie is incorrect, the responder terminates the negotiation.

The cookie challenging mechanism automatically stops working when the number of half-open IKE SAs drops below the threshold.

IKEv2 SA rekeying

For security purposes, both IKE SAs and IPsec SAs have a lifetime and must be rekeyed when the lifetime expires. An IKEv1 SA lifetime is negotiated. An IKEv2 SA lifetime, in contrast, is configured. If two peers are configured with different lifetimes, the peer with the shorter lifetime always initiates the SA rekeying. This mechanism reduces the possibility that two peers will simultaneously initiate a rekeying. Simultaneous rekeying results in redundant SAs and SA status inconsistency on the two peers.

IKEv2 message retransmission

Unlike IKEv1 messages, IKEv2 messages appear in request/response pairs. IKEv2 uses the Message ID field in the message header to identify the request/response pair. If an initiator sends a request but receives no response with the same Message ID value within a specific period of time, the initiator retransmits the request.

It is always the IKEv2 initiator that initiates the retransmission, and the retransmitted message must use the same Message ID value.

Protocols and standards

· RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)

· RFC 4306, Internet Key Exchange (IKEv2) Protocol

· RFC 4718, IKEv2 Clarifications and Implementation Guidelines

· RFC 2412, The OAKLEY Key Determination Protocol

· RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2)

Feature and hardware compatibility

Hardware series	Model	IKEv2 compatibility
WX1800H series	WX1804H	Yes
	WX1810H	Yes
	WX1820H	Yes
	WX1840H	No
WX3800H series	WX3820H WX3840H	No
WX5800H series	WX5860H	No

IKEv2 configuration task list

Determine the following parameters prior to IKEv2 configuration:

· The strength of the algorithms for IKEv2 negotiation, including the encryption algorithms, integrity protection algorithms, PRF algorithms, and DH groups. Different algorithms provide different levels of protection. A stronger algorithm means better resistance to decryption of protected data but requires more resources. Typically, the longer the key, the stronger the algorithm.

· The local and remote identity authentication methods.

? To use the pre-shared key authentication method, you must determine the pre-shared key.

? To use the RSA digital signature authentication method, you must determine the PKI domain for the local end to use. For information about PKI, see "Configuring PKI."

To configure IKEv2, perform the following tasks:

Tasks at a glance	Remarks
(Required.) Configuring an IKEv2 profile	N/A
(Required.) Configuring an IKEv2 policy	N/A
(Optional.) Configuring an IKEv2 proposal	If you specify an IKEv2 proposal in an IKEv2 policy, you must configure the IKEv2 proposal.
Configuring an IKEv2 keychain	Required when either end or both ends use the pre-shared key authentication method.
Configure global IKEv2 parameters · (Optional.) Enabling the cookie challenging feature · (Optional.) Configuring the IKEv2 DPD feature · (Optional.) Configuring the IKEv2 NAT keepalive feature · (Optional.) Configuring IKEv2 address pools	The cookie challenging feature takes effect only on IKEv2 responders.

Configuring an IKEv2 profile

An IKEv2 profile is intended to provide a set of parameters for IKEv2 negotiation. To configure an IKEv2 profile, perform the following tasks:

1. Specify the local and remote identity authentication methods.

The local and remote identity authentication methods must both be specified and they can be different. You can specify only one local identity authentication method and multiple remote identity authentication methods.

2. Configure the IKEv2 keychain or PKI domain for the IKEv2 profile to use:

? To use digital signature authentication, configure a PKI domain.

? To use pre-shared key authentication, configure an IKEv2 keychain.

3. Configure the local ID, the ID that the device uses to identify itself to the peer during IKEv2 negotiation:

? For digital signature authentication, the device can use an ID of any type. If the local ID is an IP address that is different from the IP address in the local certificate, the device uses the FQDN as the local ID. The FQDN is the device name configured by using the sysname command.

? For pre-shared key authentication, the device can use an ID of any type other than the DN.

4. Configure peer IDs.

The device compares the received peer ID with the peer IDs of its local IKEv2 profiles. If a match is found, it uses the IKEv2 profile with the matching peer ID for IKEv2 negotiation. IKEv2 profiles will be compared in descending order of their priorities.

5. Specify a local interface or IP address for the IKEv2 profile so the profile can be applied only to the specified interface or IP address. For this task, specify the local address configured in IPsec policy or IPsec policy template view (using the local-address command). If no local address is configured, specify the IP address of the interface that uses the IPsec policy.

6. Specify a priority number for the IKEv2 profile. To determine the priority of an IKEv2 profile:

a. First, the device examines the existence of the match local command. An IKEv2 profile with the match local command configured has a higher priority.

b. If a tie exists, the device compares the priority numbers. An IKEv2 profile with a smaller priority number has a higher priority.

c. If a tie still exists, the device prefers an IKEv2 profile configured earlier.

7. Configure the IKEv2 SA lifetime.

The local and remote ends can use different IKEv2 SA lifetimes. They do not negotiate the lifetime. The end with a smaller SA lifetime will initiate an SA negotiation when the lifetime expires.

8. Configure IKEv2 DPD to detect dead IKEv2 peers. You can also configure this feature in system view. If you configure IKEv2 DPD in both views, the IKEv2 DPD settings in IKEv2 profile view apply. If you do not configure IKEv2 DPD in IKEv2 profile view, the IKEv2 DPD settings in system view apply.

9. Configure the NAT keepalive interval.

Configure this task when the device is behind a NAT gateway. The device sends NAT keepalive packets regularly to its peer to prevent the NAT session from being aged because of no matching traffic.

10. Enable the configuration exchange feature.

The configuration exchange feature enables the local and remote ends to exchange configuration data, such as gateway address, internal IP address, and route. The exchange includes data request and response, and data push and response.

This feature typically applies to scenarios where branches and the headquarters communicate through virtual tunnels.

This feature enables the IPsec gateway at a branch to send IP address requests to the IPsec gateway at the headquarters. When the headquarters receives the request, it sends an IP address to the branch in the response packet. The headquarters can also actively push an IP address to the branch. The branch uses the allocated IP address as the IP address of the virtual tunnel to communicate with the headquarters.

11. Enable AAA authorization.

The AAA authorization feature enables IKEv2 to request authorization attributes, such as the IKEv2 address pool, from AAA. IKEv2 uses the address pool to assign IP addresses to remote users. For more information about AAA authorization, see "Configuring AAA."

To configure an IKEv2 profile:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an IKEv2 profile and enter IKEv2 profile view.	ikev2 profile profile-name	By default, no IKEv2 profile exists.
3. Configure the local and remote identity authentication methods.	authentication-method { local \| remote } { dsa-signature \| ecdsa-signature \| pre-share \| rsa-signature }	By default, no local or remote identity authentication method is configured.
4. Specify a keychain.	keychain keychain-name	By default, no keychain is specified for an IKEv2 profile. Perform this task when the pre-shared key authentication method is specified.
5. Specify a PKI domain.	certificate domain domain-name [ sign \| verify ]	By default, the device uses PKI domains configured in system view. Perform this task when the digital signature authentication method is specified.
6. Configure the local ID.	identity local { address { ipv4-address \| ipv6 ipv6-address } \| dn \| email email-string \| fqdn fqdn-name \| key-id key-id-string }	By default, no local ID is configured, and the device uses the IP address of the interface where the IPsec policy applies as the local ID.
7. Configure peer IDs.	match remote { certificate policy-name \| identity { address { { ipv4-address [ mask \| mask-length ] \| range low-ipv4-address high-ipv4-address } \| ipv6 { ipv6-address [ prefix-length ] \| range low-ipv6-address high-ipv6-address } } \| fqdn fqdn-name \| email email-string \| key-id key-id-string } }	By default, no peer ID is configured. You must configure a minimum of one peer ID on each of the two peers.
8. (Optional.) Specify the local interface or IP address to which the IKEv2 profile can be applied.	match local address { interface-type interface-number \| ipv4-address \| ipv6 ipv6-address }	By default, an IKEv2 profile can be applied to any local interface or IP address.
9. (Optional.) Specify a priority for the IKEv2 profile.	priority priority	By default, the priority of an IKEv2 profile is 100.
10. (Optional.) Set the IKEv2 SA lifetime for the IKEv2 profile.	sa duration seconds	By default, the IKEv2 SA lifetime is 86400 seconds.
11. (Optional.) Configure the DPD feature for the IKEv2 profile.	dpd interval interval [ retry seconds ] { on-demand \| periodic }	By default, DPD is disabled for an IKEv2 profile. The global DPD settings in system view are used. If DPD is also disabled in system view, the device does not perform DPD.
12. (Optional.) Set the IKEv2 NAT keepalive interval.	nat-keepalive seconds	By default, the global IKEv2 NAT keepalive setting is used.
13. (Optional.) Enable the configuration exchange feature.	config-exchange { request \| set { accept \| send } }	By default, all configuration exchange options are disabled.
14. (Optional.) Enable AAA authorization.	aaa authorization domain domain-name username user-name	By default, AAA authorization is disabled for IKEv2.

Configuring an IKEv2 policy

During the IKE_SA_INIT exchange, each end tries to find a matching IKEv2 policy, using the IP address of the local security gateway as the matching criterion.

· If IKEv2 policies are configured, IKEv2 searches for an IKEv2 policy that uses the IP address of the local security gateway. If no IKEv2 policy uses the IP address or the policy is using an incomplete proposal, the IKE_SA_INIT exchange fails.

· If no IKEv2 policy is configured, IKEv2 uses the system default IKEv2 policy default.

The device matches IKEv2 policies in the descending order of their priorities. To determine the priority of an IKEv2 policy:

1. First, the device examines the existence of the match local address command. An IKEv2 policy with the match local address command configured has a higher priority.

2. If a tie exists, the device compares the priority numbers. An IKEv2 policy with a smaller priority number has a higher priority.

3. If a tie still exists, the device prefers an IKEv2 policy configured earlier.

To configure an IKEv2 policy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an IKEv2 policy and enter IKEv2 policy view.	ikev2 policy policy-name	By default, the device has a system default IKEv2 policy named default.
3. Specify the local interface or address used for IKEv2 policy matching.	match local address { interface-type interface-number \| ipv4-address \| ipv6 ipv6-address }	By default, no local interface or address is used for IKEv2 policy matching, and the policy matches any local interface or address.
4. Specify a IKEv2 proposal for the IKEv2 policy.	proposal proposal-name	By default, no IKEv2 proposal is specified for an IKEv2 policy.
5. Specify a priority for the IKEv2 policy.	priority priority	By default, the priority of an IKEv2 policy is 100.

Configuring an IKEv2 proposal

An IKEv2 proposal contains security parameters used in IKE_SA_INIT exchanges, including the encryption algorithms, integrity protection algorithms, PRF algorithms, and DH groups. An algorithm specified earlier has a higher priority.

A complete IKEv2 proposal must have at least one set of security parameters, including one encryption algorithm, one integrity protection algorithm, one PRF algorithm, and one DH group.

You can specify multiple IKEv2 proposals for an IKEv2 policy. A proposal specified earlier has a higher priority.

To configure an IKEv2 proposal:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an IKEv2 proposal and enter IKEv2 proposal view.	ikev2 proposal proposal-name	The device has a system default IKEv2 proposal named default. The default proposal uses the following settings: · Encryption algorithms AES-CBC-128 and 3DES. · Integrity protection algorithms HMAC-SHA1 and HMAC-MD5. · PRF algorithms HMAC-SHA1 and HMAC-MD5. · DH groups 2 and 5.
3. Specify the encryption algorithms.	encryption { 3des-cbc \| aes-cbc-128 \| aes-cbc-192 \| aes-cbc-256 \| aes-ctr-128 \| aes-ctr-192 \| aes-ctr-256 \| camellia-cbc-128 \| camellia-cbc-192 \| camellia-cbc-256 \| des-cbc } *	By default, an IKEv2 proposal does not have an encryption algorithm.
4. Specify the integrity protection algorithms.	integrity { aes-xcbc-mac \| md5 \| sha1 \| sha256 \| sha384 \| sha512 } *	By default, an IKEv2 proposal does not have an integrity protection algorithm.
5. Specify the PRF algorithms.	prf { aes-xcbc-mac \| md5 \| sha1 \| sha256 \| sha384 \| sha512 } *	By default, an IKEv2 proposal does not have an PRF algorithm.
6. Specify the DH groups.	dh { group1 \| group14 \| group2 \| group24 \| group5 \| group19 \| group20 } *	By default, an IKEv2 proposal does not have a DH group.

Configuring an IKEv2 keychain

An IKEv2 keychain specifies the pre-shared keys used for IKEv2 negotiation.

An IKEv2 keychain can have multiple IKEv2 peers. Each peer has a symmetric pre-shared key or an asymmetric pre-shared key pair, and information for identifying the peer (such as the peer's host name, IP address or address range, or ID).

An IKEv2 negotiation initiator uses the peer host name or IP address/address range as the matching criterion to search for a peer. A responder uses the peer host IP address/address range or ID as the matching criterion to search for a peer.

To configure an IKEv2 keychain:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an IKEv2 keychain and enter IKEv2 keychain view.	ikev2 keychain keychain-name	By default, no IKEv2 keychain exists.
3. Create an IKEv2 peer and enter IKEv2 peer view.	peer name	By default, no IKEv2 peer exists.
4. Configure the information for identifying the IKEv2 peer.	· To configure a host name for the peer: hostname host-name · To configure a host IP address or address range for the peer: address { ipv4-address [ mask \| mask-length ] \| ipv6 ipv6-address [ prefix-length ] } · To configure an ID for the peer: identity { address { ipv4-address \| ipv6 { ipv6-address } } \| fqdn fqdn-name \| email email-string \| key-id key-id-string }	By default, no host name, host IP address, address range, or identity information is configured for an IKEv2 peer. You must configure different IP addresses/address ranges for different peers.
5. Configure a pre-shared key for the peer.	pre-shared-key [ local \| remote ] { ciphertext \| plaintext } string	By default, no pre-shared key is configured for an IKEv2 peer.

Configure global IKEv2 parameters

Enabling the cookie challenging feature

Enable cookie challenging on responders to protect them against DoS attacks that use a large number of source IP addresses to forge IKE_SA_INIT requests.

To enable cookie challenging:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable cookie challenging.	ikev2 cookie-challenge number	By default, IKEv2 cookie challenging is disabled..

Configuring the IKEv2 DPD feature

IKEv2 DPD detects dead IKEv2 peers in periodic or on-demand mode.

· Periodic DPD—Verifies the liveness of an IKEv2 peer by sending DPD messages at regular intervals.

· On-demand DPD—Verifies the liveness of an IKEv2 peer by sending DPD messages before sending data.

? Before the device sends data, it identifies the time interval for which the last IPsec packet has been received from the peer. If the time interval exceeds the DPD interval, it sends a DPD message to the peer to detect its liveness.

? If the device has no data to send, it never sends DPD messages.

If you configure IKEv2 DPD in both IKEv2 profile view and system view, the IKEv2 DPD settings in IKEv2 profile view apply. If you do not configure IKEv2 DPD in IKEv2 profile view, the IKEv2 DPD settings in system view apply.

To configure global IKEv2 DPD:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Configure global IKEv2 DPD.	ikev2 dpd interval interval [ retry seconds ] { on-demand \| periodic }	By default, global DPD is disabled.

Configuring the IKEv2 NAT keepalive feature

Configure this feature on the IKEv2 gateway behind the NAT device. The gateway then sends NAT keepalive packets regularly to its peer to keep the NAT session alive, so that the peer can access the device.

The NAT keepalive interval must be shorter than the NAT session lifetime.

This feature takes effect after the device detects the NAT device.

To configure the IKEv2 NAT keepalive feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Set the IKEv2 NAT keepalive interval.	ikev2 nat-keepalive seconds	By default, the IKEv2 NAT keepalive interval is 10 seconds.

Configuring IKEv2 address pools

To perform centralized management on remote users, an IPsec gateway can use an address pool to assign private IP addresses to remote users.

You must use an IKEv2 address pool together with AAA authorization by specifying the IKEv2 address pool as an AAA authorization attribute. For more information about AAA authorization, see "Configuring AAA."

To configure IKEv2 address pools:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Configure an IKEv2 IPv4 address pool.	ikev2 address-group group-name start-ipv4-address end-ipv4-address [ mask \| mask-length ]	By default, no IKEv2 IPv4 address pool exists.
3. Configure an IKEv2 IPv6 address pool.	ikev2 ipv6-address-group group-name prefix prefix/prefix-len assign-len assign-len	By default, no IKEv2 IPv6 address pool exists.

Displaying and maintaining IKEv2

Execute display commands in any view and reset commands in user view.

Task	Command
Display the IKEv2 proposal configuration.	display ikev2 proposal [ name \| default ]
Display the IKEv2 policy configuration.	display ikev2 policy [ policy-name \| default ]
Display the IKEv2 profile configuration.	display ikev2 profile [ profile-name ]
Display the IKEv2 SA information.	display ikev2 sa [ count \| [ { local \| remote } { ipv4-address \| ipv6 ipv6-address } ] [ verbose [ tunnel tunnel-id ] ] ]
Display IKEv2 statistics.	display ikev2 statistics
Delete IKEv2 SAs and the child SAs negotiated through the IKEv2 SAs.	reset ikev2 sa [ [ { local \| remote } { ipv4-address \| ipv6 ipv6-address } ] \| tunnel tunnel-id ] [ fast ]
Clear IKEv2 statistics.	reset ikev2 statistics

Troubleshooting IKEv2

IKEv2 negotiation failed because no matching IKEv2 proposals were found

Symptom

The IKEv2 SA is in IN-NEGO status.

<Sysname> display ikev2 sa

Tunnel ID Local Remote Status

---------------------------------------------------------------------------

5 123.234.234.124/500 123.234.234.123/500 IN-NEGO

Status:

IN-NEGO: Negotiating, EST: Establish, DEL:Deleting

Analysis

Certain IKEv2 proposal settings are incorrect.

Solution

1. Examine the IKEv2 proposal configuration to see whether the two ends have matching IKEv2 proposals.

2. Modify the IKEv2 proposal configuration to make sure the two ends have matching IKEv2 proposals.

IPsec SA negotiation failed because no matching IPsec transform sets were found

Symptom

The display ikev2 sa command shows that the IKEv2 SA negotiation succeeded and the IKEv2 SA is in EST status. The display ipsec sa command shows that the expected IPsec SAs have not been negotiated yet.

Analysis

Certain IPsec policy settings are incorrect.

Solution

1. Examine the IPsec configuration to see whether the two ends have matching IPsec transform sets.

2. Modify the IPsec configuration to make sure the two ends have matching IPsec transform sets.

IPsec tunnel establishment failed

Symptom

The ACLs and IKEv2 proposals are correctly configured on both ends. The two ends cannot establish an IPsec tunnel or cannot communicate through the established IPsec tunnel.

Analysis

The IKEv2 SA or IPsec SAs on either end are lost. The reason might be that the network is unstable and the device reboots.

Solution

1. Use the display ikev2 sa command to examine whether an IKEv2 SA exists on both ends. If the IKEv2 SA on one end is lost, delete the IKEv2 SA on the other end by using the reset ikev2 sa command and trigger new negotiation. If an IKEv2 SA exists on both ends, go to the next step.

2. Use the display ipsec sa command to examine whether IPsec SAs exist on both ends. If the IPsec SAs on one end are lost, delete the IPsec SAs on the other end by using the reset ipsec sa command and trigger new negotiation.

Configuring SSH

Overview

Secure Shell (SSH) is a network security protocol. Using encryption and authentication, SSH can implement secure remote access and file transfer 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 supports the following SSH applications:

· Secure Telnet—Stelnet provides secure and reliable network terminal access services. Through Stelnet, a user can securely log in to a remote server. Stelnet can protect devices against attacks, such as IP spoofing and plain text password interception. The device can act as an Stelnet server or an Stelnet client.

· Secure File Transfer Protocol—Based on SSH2, SFTP uses SSH connections to provide secure file transfer. The device can act as an SFTP server, allowing a remote user to log in to the SFTP server for secure file management and transfer. The device can also act as an SFTP client, enabling a user to log in from the device to a remote device for secure file transfer.

· Secure Copy—Based on SSH2, SCP offers a secure method to copy files. The device can act as an 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 device for secure file transfer.

· NETCONF over SSH—Based on SSH2, it enables users to securely log in to the device through SSH and perform NETCONF operations on the device through the NETCONF-over-SSH connections. The device can act only as a NETCONF-over-SSH server. For more information about NETCONF, see Network Management and Monitoring Configuration Guide.

When acting as an SSH client or server, the device supports the following SSH versions:

· When acting as an SSH client, the device supports only SSH2.

· When acting as an Stelnet, SFTP, or SCP server, the device supports both SSH2 and SSH1.

· When acting as a NETCONF-over-SSH server, the device supports only SSH2.

How SSH works

This section uses SSH2 as an example to describe the stages to establish an SSH session.

Table 9 Stages to establish an SSH session

Stages	Description
Connection establishment	The SSH server listens to 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.
Algorithm negotiation	SSH supports multiple algorithms. Based on the local algorithms, the two parties negotiate the following algorithms: · Key exchange algorithm for generating session keys. · Encryption algorithm for encrypting data. · Public key algorithm for the digital signature and authentication. · HMAC algorithm for protecting data integrity.
Key exchange	The two parties use the DH exchange algorithm to dynamically generate the session keys and session ID. · 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 the authentication, the client sends a session request to the server to request the establishment of a session (or request the Stelnet, SFTP, SCP, or NETCONF service).
Interaction	After the server grants the request, the client and the server start to communicate with each other in the session. In this stage, you can paste commands in text format and execute them at the CLI. The text pasted at one time must be no more than 2000 bytes. To execute the commands successfully, H3C recommends that you paste commands that are in the same view. To execute commands of more than 2000 bytes, save the commands in a configuration file, upload the file to the server through SFTP, and use it to restart the server.

SSH authentication methods

This section describes authentication methods that are supported by the device when it acts as an SSH server.

Password authentication

The SSH server authenticates a client through the AAA mechanism. The password authentication process is as follows:

1. The client sends the server an authentication request that includes the encrypted username and password.

2. The server performs the following operations:

a. Decrypts the request to get the username and password in plain text.

b. Verifies the username and password locally or through remote AAA authentication.

c. Informs the client of the authentication result.

If the remote AAA server requires the user to enter a password for secondary authentication, it send the SSH server an authentication response carrying 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 server examines the password validity. If the password is valid, the SSH server returns an authentication success message to the client.

For more information about AAA, see "Configuring AAA."

NOTE:

SSH1 clients do not support secondary password authentication that is initiated by the AAA server.

Publickey authentication

The server authenticates a client by verifying the digital signature of the client. The publickey authentication process is as follows:

1. The client sends the server a publickey authentication request that includes the username, public key, and public key algorithm name.

If the digital certificate of the client is required in authentication, the client also encapsulates the digital certificate in the authentication request. The digital certificate carries the public key information of the client.

2. The server verifies the client's public key.

? If the public key is invalid, the server informs the client of the authentication failure.

? If the public key is valid, the server requests the digital signature of the client. After receiving the signature, the server uses the public key to verify the signature and informs the client of the authentication result.

When acting as an SSH server, the device supports using the public key algorithms DSA, ECDSA, and RSA to verify digital signatures.

When acting as an SSH client, the device supports using the public key algorithms DSA, ECDSA, and RSA to generate digital signatures.

For more information about public key configuration, see "Managing public keys."

Password-publickey authentication

The server requires SSH2 clients to pass both password authentication and publickey authentication. However, an SSH1 client only needs to pass either authentication.

Any authentication

The server requires clients to pass password authentication or publickey authentication.

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

Configuring the device as an SSH server

SSH server configuration task list

Tasks at a glance	Remarks
(Required.) Generating local key pairs	N/A
(Required.) Enabling the Stelnet server	Required only for Stelnet servers.
(Required.) Enabling the SFTP server	Required only for SFTP servers.
(Required.) Enabling the SCP server	Required only for SCP servers.
(Required.) Enabling NETCONF over SSH	Required only for NETCONF-over-SSH servers.
(Required.) Configuring the user lines for SSH login	Required only for Stelnet and NETCONF-over-SSH servers.
(Required.) Configuring a client's host public key	Required if the authentication method is publickey, password-publickey, or any.
Configuring the PKI domain for verifying the client's digital certificate	See "Configuring PKI." Required if the following conditions exist: · The authentication method is publickey. · The client sends its public key to the server through a digital certificate for validity check. The PKI domain must have the CA certificate to verify the client's digital certificate.
(Required/optional.) Configuring an SSH user	Required if the authentication method is publickey, password-publickey, or any. Optional if the authentication method is password.
(Optional.) Configuring the SSH management parameters	N/A

Generating local key pairs

The DSA, ECDSA, or RSA key pairs on the SSH server are required for generating the session keys and session ID in the key exchange stage. They 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 the client saved locally. If the keys are consistent, the client uses the locally saved server's public key to decrypt the digital signature received from the server. If the decryption succeeds, the server passes the authentication.

The SSH application starts when you execute an SSH server command on the device. If the device does not have RSA key pairs with default names, the device automatically generates one RSA server key pair and one RSA host key pair. Both key pairs use their default names.

You can also use the public-key local create command to generate DSA, ECDSA, or RSA key pairs on the device.

Configuration restrictions and guidelines

When you generate local key pairs, follow these restrictions and guidelines:

· Local DSA, ECDSA, and RSA key pairs for SSH use default names. You cannot assign names to the key pairs.

· To support SSH clients that use different types of key pairs, generate DSA, ECDSA, and RSA key pairs on the SSH server.

· The public-key local create rsa command generates a server key pair and a host key pair for RSA. 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 separately 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 one DSA host key pair. The key modulus length must be less than 2048 bits when you generate the DSA key pair on the SSH server. SSH1 does not support the DSA algorithm.

· The public-key local create ecdsa secp256r1 command generates only one ECDSA host key pair.

Configuration procedure

To generate local key pairs on the SSH server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Generate local key pairs.	public-key local create { dsa \| ecdsa secp256r1 \| rsa }	By default, no local key pairs exist on the server.

Enabling the Stelnet server

After you enable the Stelnet server on the device, a client can log in to the device through Stelnet.

To enable the Stelnet server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the Stelnet server.	ssh server enable	By default, the Stelnet server is disabled.

Enabling the SFTP server

After you enable the SFTP server on the device, a client can log in to the device through SFTP.

When acting as an SFTP server, the device does not support SFTP connections initiated by SSH1 clients.

To enable the SFTP server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the SFTP server.	sftp server enable	By default, the SFTP server is disabled.

Enabling the SCP server

After you enable the SCP server on the device, a client can log in to the device through SCP.

When acting as an SCP server, the device does not support SCP connections initiated by SSH1 clients.

To enable the SCP server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the SCP server.	scp server enable	By default, the SCP server is disabled.

Enabling NETCONF over SSH

After you enable NETCONF over SSH on the device, a client can perform NETCONF operations on the device through a NETCONF-over-SSH connection.

When acting as a server in the NETCONF-over-SSH connection, the device does not support connection requests initiated by SSH1 clients.

To enable NETCONF over SSH:

Step

Command

Remark

1. Enter system view.

system-view

N/A

2. Enable NETCONF over SSH.

netconf ssh server enable

By default, NETCONF over SSH is disabled.

For more information about NETCONF over SSH commands, see Network Management and Monitoring Command Reference.

Configuring the user lines for SSH login

Depending on the SSH application, an SSH client can be an Stelnet client, SFTP client, SCP client, or NETCONF-over-SSH client.

Only Stelnet and NETCONF-over-SSH clients require the user line configuration. The user line configuration takes effect on the clients at the next login.

To configure the user lines for Stelnet and NETCONF-over-SSH clients:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter VTY user line view.	line vty number [ ending-number ]	N/A
3. Set the login authentication mode to scheme.	authentication-mode scheme	By default, the authentication mode is password. For more information about this command, see Fundamentals Command Reference.

Configuring a client's host public key

In publickey authentication, the server compares the SSH username and the client's host public key received from the client with the locally saved SSH username and the client's host public key. If they are the same, the server checks the digital signature that the client sends. The client generates the digital signature by using the private key that is paired with the client's host public key.

For publickey authentication, password-publickey authentication, or any authentication, you must perform the following tasks:

1. Configure the client's DSA, ECDSA, or RSA host public key on the server.

H3C recommends that you configure no more than 20 SSH client's host public keys on an SSH server.

2. Specify the associated host private key on the client to generate the digital signature.

If the device acts 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. H3C recommends that you import the client's host public key.

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. Configure a client's host public key.	Enter the content of the client's host public key	The host public key must be in the DER encoding format without being converted. When you enter the content of a client's host public key, you can use spaces and carriage returns between characters. When you save the host public key, spaces and carriage returns are removed automatically. For more information, see "Managing public keys."
4. Return to system view.	peer-public-key end	N/A

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

To import a client's host public key from the public key file:

Step	Command
1. Enter system view.	system-view
2. Import a client's public key from the public key file.	public-key peer keyname import sshkey filename

Configuring an SSH user

Configure an SSH user and a local user depending on the authentication method.

· If the authentication method is publickey, you must create an SSH user and a local user on the SSH server. The two users must have the same username, so that the SSH user can be assigned the correct working directory and user role.

· If the authentication method is password, you must perform one of the following tasks:

? For local authentication, configure a local user on the SSH server.

? For remote authentication, configure an SSH user on a remote authentication server, for example, a RADIUS server.

You do not need to create an SSH user by using the ssh user command. 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.

· If the authentication method is password-publickey or any, you must create an SSH user on the SSH server and perform one of the following tasks:

? For local authentication, configure a local user on the SSH server.

? For remote authentication, configure an SSH user on a remote authentication server, for example, a RADIUS server.

In either case, the local user or the SSH user configured on the remote authentication server must have the same username as the SSH user.

For information about configuring local users and remote authentication, see "Configuring AAA."

Configuration restrictions and guidelines

When you configure an SSH user, follow these restrictions and guidelines:

· An SSH server supports up to 1024 SSH users.

· For an SFTP or SCP user, the working directory depends on the authentication method.

? If the authentication method is password, the working directory is authorized by AAA.

? If the authentication method is publickey or password-publickey, the working folder is specified by the authorization-attribute command in the associated local user view.

· For an SSH user, the user role also depends on the authentication method.

? If the authentication method is password, the user role is authorized by the remote AAA server or the local device.

? If the authentication method is publickey or password-publickey, the user role is specified by the authorization-attribute command in the associated local user view.

· If you change the authentication parameters for a logged-in SSH user, the change takes effect on the user at the next login.

· For all authentication methods except password authentication, you must specify a client's host public key or digital certificate.

? For a client that sends the user's public key information directly to the server, specify the client's host public key on the server. The specified 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, specify the PKI domain on the server. This PKI domain verifies the client's digital certificate. For successful verification, the specified PKI domain must have the correct CA certificate. For more information about configuring a PKI domain, see "Configuring PKI."

Configuration procedure

To configure an SSH user, and specify the service type and authentication method:

Step	Command
1. Enter system view.	system-view
2. Create an SSH user, and specify the service type and authentication method.	ssh user username service-type { all \| netconf \| scp \| sftp \| stelnet } authentication-type { password \| { any \| password-publickey \| publickey } assign { pki-domain domain-name \| publickey keyname } }

Configuring the SSH management parameters

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the SSH server to support SSH1 clients.	ssh server compatible-ssh1x enable	By default, the SSH server does not support SSH1 clients.
3. Set the minimum interval for updating the RSA server key pair.	ssh server rekey-interval hours	By default, the RSA server key pair is not updated. This command takes effect only on SSH1 users.
4. Set the SSH user authentication timeout timer.	ssh server authentication-timeout time-out-value	The default setting is 60 seconds. If a user does not finish the authentication when the timeout timer expires, the connection cannot be established.
5. Set the maximum number of SSH authentication attempts.	ssh server authentication-retries times	The default setting is 3. If the authentication method is any, the total number of publickey authentication attempts and password authentication attempts cannot exceed the upper limit.
6. Specify an ACL to control SSH user connections.	· Control IPv4 SSH user connections: ssh server acl { basic-acl-number \| advanced-acl-number \| mac mac-acl-number } · Control IPv6 SSH user connections: ssh server ipv6 acl { ipv6 basic-acl-number \| ipv6 advanced-acl-number \| mac mac-acl-number }	By default, no ACLs are specified and all SSH users can initiate SSH connections to the server.
7. Set the DSCP value in the packets that the SSH server sends to the SSH clients.	· Set the DSCP value in IPv4 packets: ssh server dscp dscp-value · Set the DSCP value in IPv6 packets: ssh server ipv6 dscp dscp-value	The default setting is 48. The DSCP value of a packet defines the priority of the packet and affects the transmission priority of the packet. A bigger DSCP value represents a higher priority.
8. Set the SFTP connection idle timeout timer.	sftp server idle-timeout time-out-value	The default setting is 10 minutes. When the idle timeout timer expires, the system automatically tears the connection down.
9. Specify the maximum number of concurrent online SSH users.	aaa session-limit ssh max-sessions	The default setting is 32. When the number of online SSH users reaches the upper limit, the system denies new SSH connection requests. Changing the upper limit does not affect online SSH users.

Configuring the device as an Stelnet client

Stelnet client configuration task list

Tasks at a glance	Remarks
(Required.) Generating local key pairs	Only required when the Stelnet server uses the authentication method publickey, password-publickey, or any.
(Optional.) Specifying the source IP address for outgoing SSH packets	N/A
(Required.) Establishing a connection to an Stelnet server	N/A

Generating local key pairs

Generate local key pairs on the Stelnet client when the Stelnet server uses the authentication method publickey, password-publickey, or any.

Configuration restrictions and guidelines

When you generate local key pairs on an Stelnet client, follow these restrictions and guidelines:

· Local DSA, ECDSA, and RSA key pairs for SSH use default names. You cannot assign names to the key pairs.

· The key modulus length must be less than 2048 bits when you generate a DSA key pair.

Configuration procedure

To generate local key pairs on the Stelnet client:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Generate local key pairs.	public-key local create { dsa \| ecdsa secp256r1 \| rsa }	By default, no local key pairs exist on an Stelnet client.

Specifying the source IP address for outgoing SSH packets

H3C recommends that you specify the IP address of the loopback interface as the source address for outgoing 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 the source IP address for outgoing SSH packets:

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Specify the source address for outgoing SSH packets.

· Specify the source IPv4 address for outgoing SSH packets:
ssh client source { interface interface-type interface-number | ip ip-address }

· Specify the source IPv6 address for outgoing SSH packets:
ssh client ipv6 source { interface interface-type interface-number | ipv6 ipv6-address }

By default, the source IP address for SSH packets is not configured. An IPv4 Stelnet client uses the primary IPv4 address of the output interface in the matching route as the source address of the outgoing SSH packets. An IPv6 Stelnet client automatically selects a source IPv6 address for outgoing SSH packets in compliance with RFC 3484.

Establishing a connection to an Stelnet server

When you try to access an Stelnet server, the device must use the server's host public key to authenticate the server. If the server's host public key is not configured on the device, the device will notify you to confirm whether to continue with the access.

· If you choose to continue, the device accesses the server and downloads the server's host public key.

· If you choose to not continue, the connection cannot be established.

In an insecure network, H3C recommends that you configure the server's host public key on the device.

To establish a connection to an IPv4 Stelnet server:

Task	Command	Remarks
Establish a connection to an IPv4 Stelnet server.	ssh2 server [ port-number ] [ identity-key { dsa \| ecdsa \| rsa } \| prefer-compress zlib \| prefer-ctos-cipher { 3des-cbc \| aes128-cbc \| aes256-cbc \| des-cbc } \| prefer-ctos-hmac { md5 \| md5-96 \| sha1 \| sha1-96 } \| prefer-kex { dh-group-exchange-sha1 \| dh-group1-sha1 \| dh-group14-sha1 } \| prefer-stoc-cipher { 3des-cbc \| aes128-cbc \| aes256-cbc \| des-cbc } \| prefer-stoc-hmac { md5 \| md5-96 \| sha1 \| sha1-96 } ] * [ dscp dscp-value \| escape character \| public-key keyname \| source { interface interface-type interface-number \| ip ip-address } ] *	Available in user view.

To establish a connection to an IPv6 Stelnet server:

Task	Command	Remarks
Establish a connection to an IPv6 Stelnet server.	ssh2 ipv6 server [ port-number ] [ -i interface-type interface-number ] [ identity-key { dsa \| ecdsa \| rsa } \| prefer-compress zlib \| prefer-ctos-cipher { 3des-cbc \| aes128-cbc \| aes256-cbc \| des-cbc } \| prefer-ctos-hmac { md5 \| md5-96 \| sha1 \| sha1-96 } \| prefer-kex { dh-group-exchange-sha1 \| dh-group1-sha1 \| dh-group14-sha1 } \| prefer-stoc-cipher { 3des-cbc \| aes128-cbc \| aes256-cbc \| des-cbc } \| prefer-stoc-hmac { md5 \| md5-96 \| sha1 \| sha1-96 } ] * [ dscp dscp-value \| escape character \| public-key keyname \| source { interface interface-type interface-number \| ipv6 ipv6-address } ] *	Available in user view.

Configuring the device as an SFTP client

SFTP client configuration task list

Tasks at a glance	Remarks
(Required.) Generating local key pairs	Only required when the SFTP server uses the authentication method publickey, password-publickey, or any.
(Optional.) Specifying the source IP address for outgoing SFTP packets	N/A
(Required.) Establishing a connection to an SFTP server	N/A
(Optional.) Working with SFTP directories	N/A
(Optional.) Working with SFTP files	N/A
(Optional.) Displaying help information	N/A
(Optional.) Terminating the connection with the SFTP server	N/A

Generating local key pairs

Generate local key pairs on the SFTP client when the SFTP server uses the authentication method publickey, password-publickey, or any.

Configuration restrictions and guidelines

When you generate local key pairs on an SFTP client, follow these restrictions and guidelines:

· Local DSA, ECDSA, and RSA key pairs for SSH use default names. You cannot assign names to the key pairs.

· The key modulus length must be less than 2048 bits when you generate a DSA key pair.

Configuration procedure

To generate local key pairs on the SFTP client:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Generate local key pairs.	public-key local create { dsa \| ecdsa secp256r1 \| rsa }	By default, no local key pairs exist on an SFTP client.

Specifying the source IP address for outgoing SFTP packets

H3C recommends that you specify the IP address of the loopback interface as the source address for outgoing SFTP packets for the following purposes:

· Ensuring the communication between the SFTP client and the SFTP server.

· Improving the manageability of SFTP clients in authentication service.

To specify the source IP address for outgoing SFTP packets:

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Specify the source address for outgoing SFTP packets.

· Specify the source IPv4 address for outgoing SFTP packets:
sftp client source { ip ip-address | interface interface-type interface-number }

· Specify the source IPv6 address for outgoing SFTP packets:
sftp client ipv6 source { ipv6 ipv6-address | interface interface-type interface-number }

By default, the source IP address for outgoing SFTP packets is not configured. An IPv4 SFTP client uses the primary IPv4 address of the output interface in the matching route as the source address of the outgoing SFTP packets. An IPv6 SFTP client automatically selects a source IPv6 address for the outgoing SFTP packets in compliance with RFC 3484.

Establishing a connection to an SFTP server

When you try to access an SFTP server, the device must use the server's host public key to authenticate the server. If the server's host public key is not configured on the device, the device will notify you to confirm whether to continue with the access.

· If you choose to continue, the device accesses the server and downloads the server's host public key.

· If you choose to not continue, the connection cannot be established.

In an insecure network, H3C recommends that you configure the server's host public key on the device.

After the connection is established, you can directly enter SFTP client view on the server to perform file or directory operations.

To establish a connection to an IPv4 SFTP server:

Task	Command	Remarks
Establish a connection to an IPv4 SFTP server.	sftp server [ port-number ] [ identity-key { dsa \| ecdsa \| rsa } \| prefer-compress zlib \| prefer-ctos-cipher { 3des-cbc \| aes128-cbc \| aes256-cbc \| des-cbc } \| prefer-ctos-hmac { md5 \| md5-96 \| sha1 \| sha1-96 } \| prefer-kex { dh-group-exchange-sha1 \| dh-group1-sha1 \| dh-group14-sha1 } \| prefer-stoc-cipher { 3des-cbc \| aes128-cbc \| aes256-cbc \| des-cbc } \| prefer-stoc-hmac { md5 \| md5-96 \| sha1 \| sha1-96 } ] * [ dscp dscp-value \| public-key keyname \| source { interface interface-type interface-number \| ip ip-address } ] *	Available in user view.

To establish a connection to an IPv6 SFTP server:

Task	Command	Remarks
Establish a connection to an IPv6 SFTP server.	sftp ipv6 server [ port-number ] [ -i interface-type interface-number ] [ identity-key { dsa \| ecdsa \| rsa } \| prefer-compress zlib \| prefer-ctos-cipher { 3des-cbc \| aes128-cbc \| aes256-cbc \| des-cbc } \| prefer-ctos-hmac { md5 \| md5-96 \| sha1 \| sha1-96 } \| prefer-kex { dh-group-exchange-sha1 \| dh-group1-sha1 \| dh-group14-sha1 } \| prefer-stoc-cipher { 3des-cbc \| aes128-cbc \| aes256-cbc \| des-cbc } \| prefer-stoc-hmac { md5 \| md5-96 \| sha1 \| sha1-96 } ] * [ dscp dscp-value \| public-key keyname \| source { interface interface-type interface-number \| ipv6 ipv6-address } ] *	Available in user view.

Working with SFTP directories

Task	Command	Remarks
Change the working directory on the SFTP server.	cd [ remote-path ]	Available in SFTP client view.
Return to the upper-level directory.	cdup	Available in SFTP client view.
Display the current working directory on the SFTP server.	pwd	Available in SFTP client view.
Display files under a directory.	· dir [ -a \| -l ] [ remote-path ] · ls [ -a \| -l ] [ remote-path ]	Available in SFTP client view. The dir command has the same function as the ls command.
Change the name of a directory on the SFTP server.	rename oldname newname	Available in SFTP client view.
Create a new directory on the SFTP server.	mkdir remote-path	Available in SFTP client view.
Delete one or more directories from the SFTP server.	rmdir remote-path	Available in SFTP client view.

Working with SFTP files

Task	Command	Remarks
Change the name of a file on the SFTP server.	rename old-name new-name	Available in SFTP client view.
Download a file from the SFTP server and save it locally.	get remote-file [ local-file ]	Available in SFTP client view.
Upload a local file to the SFTP server.	put local-file [ remote-file ]	Available in SFTP client view.
Display files under a directory.	· dir [ -a \| -l ] [ remote-path ] · ls [ -a \| -l ] [ remote-path ]	Available in SFTP client view. The dir command has the same function as the ls command.
Delete one or more directories from the SFTP server.	· delete remote-file · remove remote-file	Available in SFTP client view. The delete command has the same function as the remove command.

Displaying help information

Task

Command

Remarks

Display the help information of SFTP client commands.

· help

· ?

Available in SFTP client view.

Terminating the connection with the SFTP server

Task

Command

Remarks

Terminate the connection with the SFTP server and return to user view.

· bye

· exit

· quit

Available in SFTP client view.

These three commands have the same function.

Configuring the device as an SCP client

SCP client configuration task list

Tasks at a glance	Remarks
(Required.) Generating local key pairs	Only required when the SCP server uses the authentication method publickey, password-publickey, or any.
(Required.) Establishing a connection to an SCP server	N/A

Generating local key pairs

Generate local key pairs on the SCP client when the SCP server uses the authentication method publickey, password-publickey, or any.

Configuration restrictions and guidelines

When you generate local key pairs on an SCP client, follow these restrictions and guidelines:

· Local DSA, ECDSA, and RSA key pairs for SSH use default names. You cannot assign names to the key pairs.

· The key modulus length must be less than 2048 bits when you generate a DSA key pair.

Configuration procedure

To generate local key pairs on the SCP client:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Generate local key pairs.	public-key local create { dsa \| ecdsa secp256r1 \| rsa }	By default, no local key pairs exist on an SCP client.

Establishing a connection to an SCP server

When you try to access an SCP server, the device must use the server's host public key to authenticate the server. If the server's host public key is not configured on the device, the device will notify you to confirm whether to continue with the access.

· If you choose to continue, the device accesses the server and downloads the server's host public key.

· If you choose to not continue, the connection cannot be established.

In an insecure network, H3C recommends that you configure the server's host public key on the device.

To establish a connection to an IPv4 SCP server:

Task	Command	Remarks
Connect to an IPv4 SCP server, and transfer files with the server.	scp server [ port-number ] { put \| get } source-file-name [ destination-file-name ] [ identity-key { dsa \| ecdsa \| rsa } \| prefer-compress zlib \| prefer-ctos-cipher { 3des-cbc \| aes128-cbc \| aes256-cbc \| des-cbc } \| prefer-ctos-hmac { md5 \| md5-96 \| sha1 \| sha1-96 } \| prefer-kex { dh-group-exchange-sha1 \| dh-group1-sha1 \| dh-group14-sha1 } \| prefer-stoc-cipher { 3des-cbc \| aes128-cbc \| aes256-cbc \| des-cbc } \| prefer-stoc-hmac { md5 \| md5-96 \| sha1 \| sha1-96 } ] * [ public-key keyname \| source { interface interface-type interface-number \| ip ip-address } ] *	Available in user view.

To establish a connection to an IPv6 SCP server:

Task	Command	Remarks
Connect to an IPv6 SCP server, and transfer files with the server.	scp ipv6 server [ port-number ] [ -i interface-type interface-number ] { put \| get } source-file-name [ destination-file-name ] [ identity-key { dsa \| ecdsa \| rsa } \| prefer-compress zlib \| prefer-ctos-cipher { 3des-cbc \| aes128-cbc \| aes256-cbc \| des-cbc } \| prefer-ctos-hmac { md5 \| md5-96 \| sha1 \| sha1-96 } \| prefer-kex { dh-group-exchange-sha1 \| dh-group1-sha1 \| dh-group14-sha1 } \| prefer-stoc-cipher { 3des-cbc \| aes128-cbc \| aes256-cbc \| des-cbc } \| prefer-stoc-hmac { md5 \| md5-96 \| sha1 \| sha1-96 } ] * [ public-key keyname \| source { interface interface-type interface-number \| ipv6 ipv6-address } ] *	Available in user view.

Specifying algorithms for SSH2

Perform this task to specify the algorithms that the SSH2 server and the SSH2 client use in the algorithm negotiation stage when they establish a session. The session type can be Stelnet, SFTP, or SCP.

The specified SSH2 algorithms do not affect SSH1 sessions.

Specifying key exchange algorithms for SSH2

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Specify key exchange algorithms for SSH2.

ssh2 algorithm key-exchange { dh-group-exchange-sha1 | dh-group14-sha1 | dh-group1-sha1 } *

If you specify the algorithms, SSH2 uses only the specified algorithms for algorithm negotiation. The algorithm specified earlier has a higher priority during negotiation.

If you do not specify any algorithms, SSH2 uses the key exchange algorithms dh-group-exchange-sha1, dh-group14-sha1, and dh-group1-sha1 in descending priority for algorithm negotiation.

Specifying public key algorithms for SSH2

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Specify public key algorithms for SSH2.

ssh2 algorithm public-key { ecdsa | dsa | rsa } *

If you specify the algorithms, SSH2 uses only the specified algorithms for algorithm negotiation. The algorithm specified earlier has a higher priority during negotiation.

If you do not specify any algorithms, SSH2 uses the public key algorithms ecdsa, dsa, and rsa in descending order of priority for algorithm negotiation.

Specifying encryption algorithms for SSH2

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Specify encryption algorithms for SSH2.

ssh2 algorithm cipher { aes128-cbc | aes256-cbc | 3des-cbc | des-cbc } *

If you specify the algorithms, SSH2 uses only the specified algorithms for algorithm negotiation. The algorithm specified earlier has a higher priority during negotiation.

If you do not specify any algorithms, SSH2 uses the encryption algorithms aes128-cbc, aes256-cbc, 3des-cbc, and des-cbc in descending order of priority for algorithm negotiation.

Specifying MAC algorithms for SSH2

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Specify MAC algorithms for SSH2.

ssh2 algorithm mac { sha1 | sha1-96 | md5 | md5-96 } *

If you specify the algorithms, SSH2 uses only the specified algorithms for algorithm negotiation. The algorithm specified earlier has a higher priority during negotiation.

If you do not specify any algorithms, SSH2 uses the MAC algorithms sha1, sha1-96, md5, and md5-96 in descending order of priority for algorithm negotiation.

Displaying and maintaining SSH

Execute display commands in any view.

Task	Command
Display the source IP address configured for the SFTP client.	display sftp client source
Display the source IP address configured for the Stelnet client.	display ssh client source
Display SSH server status or sessions.	display ssh server { session [ slot slot-number ] \| status }
Display SSH user information on the SSH server.	display ssh user-information [ username ]
Display the public keys of the local key pairs.	display public-key local { dsa \| ecdsa \| rsa } public [ name publickey-name ]
Display information about peer public keys.	display public-key peer [ brief \| name publickey-name ]
Display algorithms used by SSH2 in the algorithm negotiation stage.	display ssh2 algorithm

Stelnet configuration examples

Password authentication enabled Stelnet server configuration example

Network requirements

As shown in Figure 98:

· The route between the wireless client and the AC is reachable.

· The AC acts as the Stelnet server and uses password authentication.

· The username and password of the Stelnet client are saved on the AC.

Establish a connection between the client and the AC, so you can log in to the AC to manage configurations.

Figure 98 Network diagram

Configuration procedure

1. Configure the Stelnet server:

# Generate RSA key pairs.

<AC> system-view

[AC] public-key local create rsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

........................++++++

...................++++++

..++++++++

............++++++++

Create the key pair successfully.

# Generate a DSA key pair.

[AC] public-key local create dsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

.++++++++++++++++++++++++++++++++++++++++++++++++++*

........+......+.....+......................................+

...+.................+..........+...+.

Create the key pair successfully.

# Generate an ECDSA key pair.

[AC] public-key local create ecdsa secp256r1

Generating Keys...

Create the key pair successfully.

# Enable the Stelnet server.

[AC] ssh server enable

# Assign an IP address to VLAN-interface 2. The Stelnet client uses this address as the destination 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 lines.

[AC] line vty 0 15

[AC-line-vty0-15] authentication-mode scheme

[AC-line-vty0-15] quit

# Create a local device management user named client001.

[AC] local-user client001 class manage

# Set the password to aabbcc in plain text for local user client001.

[AC-luser-manage-client001] password simple aabbcc

# Authorize local user client001 to use the SSH service.

[AC-luser-manage-client001] service-type ssh

# Assign the network-admin user role to local user client001.

[AC-luser-manage-client001] authorization-attribute user-role network-admin

[AC-luser-manage-client001] quit

# Create an SSH user named client001. Specify the service type as stelnet and the authentication method as password for the user.

[AC] ssh user client001 service-type stelnet authentication-type password

2. Establish a connection to the Stelnet server:

There are different types of Stelnet client software, such as PuTTY and OpenSSH. This example uses an Stelnet client that runs PuTTY version 0.58.

To establish a connection to the Stelnet server:

a. Launch PuTTY.exe to enter the interface shown in Figure 99.

b. In the Host Name (or IP address) field, enter the IP address (192.168.1.40) of the Stelnet server.

Figure 99 Specifying the host name (or IP address)

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 in this example) and password (aabbcc in this example), you can enter the CLI of the server.

Publickey authentication enabled Stelnet server configuration example

Network requirements

As shown in Figure 100:

· The route between the wireless client and the AC is reachable.

· The AC acts as the Stelnet server, and it uses publickey authentication and the RSA public key algorithm.

Establish a connection between the client and the AC, so you can log in to the AC to manage configurations.

Figure 100 Network diagram

Configuration procedure

In the server configuration, the client's host public key is required. Use the client software to generate RSA key pairs on the client before configuring the Stelnet server.

There are different types of Stelnet client software, such as PuTTY and OpenSSH. This example uses an Stelnet client that runs PuTTY version 0.58.

The configuration procedure is as follows:

1. Generate RSA key pairs on the Stelnet client:

a. Run PuTTYGen.exe on the client, select SSH-2 RSA and click Generate.

Figure 101 Generating a key pair on the client

b. Continuously move the mouse and do not place the mouse over the green progress bar shown in Figure 102. Otherwise, the progress bar stops moving and the key pair generating progress stops.

Figure 102 Generating process

c. After the key pair is generated, click Save public key to save the public key.

A file saving window appears.

Figure 103 Saving a key pair on the client

d. Enter a file name (key.pub in this example), and click Save.

e. On the page shown in Figure 103, 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:

# Generate RSA key pairs.

<AC> system-view

[AC] public-key local create rsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

........................++++++

...................++++++

..++++++++

............++++++++

Create the key pair successfully.

# Generate a DSA key pair.

[AC] public-key local create dsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

.++++++++++++++++++++++++++++++++++++++++++++++++++*

........+......+.....+......................................+

...+.................+..........+...+

Create the key pair successfully.

# Generate an ECDSA key pair.

[AC] public-key local create ecdsa secp256r1

Generating Keys...

Create the key pair successfully.

# Enable the Stelnet server.

[AC] ssh server enable

# Assign an IP address to VLAN-interface 2. The Stelnet client uses this IP address as the destination 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 lines.

[AC] line vty 0 15

[AC-line-vty0-15] authentication-mode scheme

[AC-line-vty0-15] quit

# Import the client's public key from file key.pub and name it ackey.

[AC] public-key peer ackey import sshkey key.pub

# Create an SSH user named client002. Specify the authentication method as publickey for the user, and assign the public key ackey to the user.

[AC] ssh user client002 service-type stelnet authentication-type publickey assign publickey ackey

# Create a local device management user named client002.

[AC] local-user client002 class manage

# Authorize local user client002 to use the SSH service.

[AC-luser-manage-client002] service-type ssh

# Assign the network-admin user role to local user client002.

[AC-luser-manage-client002] authorization-attribute user-role network-admin

[AC-luser-manage-client002] quit

3. Specify the private key file and establish a connection to the Stelnet server:

a. Launch PuTTY.exe on the Stelnet client to enter the interface shown in Figure 104.

b. In the Host Name (or IP address) field, enter the IP address (192.168.1.40) of the Stelnet server.

Figure 104 Specifying the host name (or IP address)

c. Select Connection > SSH from the navigation tree.

The window shown in Figure 105 appears.

d. Specify the Preferred SSH protocol version as 2.

Figure 105 Specifying the preferred SSH version

e. Select Connection > SSH > Auth from the navigation tree.

The window shown in Figure 106 appears.

f. Click Browse… to bring up the file selection window, navigate to the private key file (private.ppk in this example), and click OK.

Figure 106 Specifying the private key file

g. Click Open to connect to the server.

If the connection is successfully established, the system notifies you to enter the username. 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 107:

· The switch acts as the Stelnet server and uses password authentication.

· The username and password of the client are saved on the switch.

Establish a connection between the AC and the switch, so you can log in to the switch to manage configurations.

Figure 107 Network diagram

Configuration procedure

1. Configure the Stelnet server:

# Generate RSA key pairs.

<Switch> system-view

[Switch] public-key local create rsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

........................++++++

...................++++++

..++++++++

............++++++++

Create the key pair successfully.

# Generate a DSA key pair.

[Switch] public-key local create dsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

.++++++++++++++++++++++++++++++++++++++++++++++++++*

........+......+.....+......................................+

...+.................+..........+...+

Create the key pair successfully.

# Generate an ECDSA key pair.

[Switch] public-key local create ecdsa secp256r1

Generating Keys...

Create the key pair successfully.

# Enable the Stelnet server.

[Switch] ssh server enable

# Assign an IP address to VLAN-interface 2. The Stelnet client uses this address as the destination address of the 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 lines.

[Switch] line vty 0 15

[Switch-line-vty0-15] authentication-mode scheme

[Switch-line-vty0-15] quit

# Create a local device management user named client001.

[Switch] local-user client001 class manage

# Set the password to aabbcc in plain text for local user client001.

[Switch-luser-manage-client001] password simple aabbcc

# Authorize local user client001 to use the SSH service.

[Switch-luser-manage-client001] service-type ssh

# Assign the network-admin user role to local user client001.

[Switch-luser-manage-client001] authorization-attribute user-role network-admin

[Switch-luser-manage-client001] quit

# Create an SSH user named 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:

# Assign an IP address to 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

Before establishing a connection to the server, you can configure the server's host public key on the client to authenticate the server.

? To configure the server's host public key on the client, perform the following tasks:

# Use the display public-key local dsa public command on the server to display the server's host public key. (Details not shown.)

# Enter public key view of the client and copy the host public key of the server to the client.

[AC] public-key peer key1

Enter public key view. Return to system view with "peer-public-key end" command.

[AC-pkey-public-key-key1]308201B73082012C06072A8648CE3804013082011F0281810

0D757262C4584C44C211F18BD96E5F0

[AC-pkey-public-key-key1]61C4F0A423F7FE6B6B85B34CEF72CE14A0D3A5222FE08CECE

65BE6C265854889DC1EDBD13EC8B274

[AC-pkey-public-key-key1]DA9F75BA26CCB987723602787E922BA84421F22C3C89CB9B0

6FD60FE01941DDD77FE6B12893DA76E

[AC-pkey-public-key-key1]EBC1D128D97F0678D7722B5341C8506F358214B16A2FAC4B3

68950387811C7DA33021500C773218C

[AC-pkey-public-key-key1]737EC8EE993B4F2DED30F48EDACE915F0281810082269009E

14EC474BAF2932E69D3B1F18517AD95

[AC-pkey-public-key-key1]94184CCDFCEAE96EC4D5EF93133E84B47093C52B20CD35D02

492B3959EC6499625BC4FA5082E22C5

[AC-pkey-public-key-key1]B374E16DD00132CE71B020217091AC717B612391C76C1FB2E

88317C1BD8171D41ECB83E210C03CC9

[AC-pkey-public-key-key1]B32E810561C21621C73D6DAAC028F4B1585DA7F42519718CC

9B09EEF0381840002818000AF995917

[AC-pkey-public-key-key1]E1E570A3F6B1C2411948B3B4FFA256699B3BF871221CC9C5D

F257523777D033BEE77FC378145F2AD

[AC-pkey-public-key-key1]D716D7DB9FCABB4ADBF6FB4FDB0CA25C761B308EF53009F71

01F7C62621216D5A572C379A32AC290

[AC-pkey-public-key-key1]E55B394A217DA38B65B77F0185C8DB8095522D1EF044B465E

8716261214A5A3B493E866991113B2D

[AC-pkey-public-key-key1]485348

[AC-pkey-public-key-key1] peer-public-key end

[AC] quit

# Establish an SSH connection to the server, and specify the host public key of the server.

<AC> ssh2 192.168.1.40 public-key key1

Username: client001

Press CTRL+C to abort.

Connecting to 192.168.1.40 port 22.

client001@192.168.1.40's password:

Enter a character ~ and a dot to abort.

******************************************************************************

* Without the owner's prior written consent, *

* no decompiling or reverse-engineering shall be allowed. *

******************************************************************************

After you enter the correct password, you successfully log in to the switch.

? If the client does not have the server's host public key, the system will notify you to confirm the further access when you access the server. Select Yes to access the server and download the server's host public key.

<AC> ssh2 192.168.1.40

Username: client001

Press CTRL+C to abort.

Connecting to 192.168.1.40 port 22.

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

Do you want to save the server public key? [Y/N]:y

client001@192.168.1.40's password:

Enter a character ~ and a dot to abort.

******************************************************************************

* Without the owner's prior written consent, *

* no decompiling or reverse-engineering shall be allowed. *

******************************************************************************

After you enter the correct password, you can access the switch successfully. At the next connection attempt, the client authenticates the server by using the saved server's host public key on the client.

Publickey authentication enabled Stelnet client configuration example

Network requirements

As shown in Figure 108, the switch acts as the Stelnet server, and it uses publickey authentication and the DSA public key algorithm.

Establish an Stelnet connection between the AC and the switch, so you can log in to the switch to manage configurations.

Figure 108 Network diagram

Configuration procedure

In the server configuration, the client's host public key is required. Generate a DSA key pair on the client before configuring the Stelnet server.

1. Configure the Stelnet client:

# Assign an IP address to 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

# Generate a DSA key pair.

[AC] public-key local create dsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

.++++++++++++++++++++++++++++++++++++++++++++++++++*

........+......+.....+......................................+

...+.................+..........+...+

Create the key pair successfully.

# Export the DSA host public key to file key.pub.

[AC] public-key local export dsa ssh2 key.pub

[AC] quit

# Transmit the public key file key.pub to the server through FTP or TFTP. (Details not shown.)

2. Configure the Stelnet server:

# Generate RSA key pairs.

<Switch> system-view

[Switch] public-key local create rsa

The range of public key modulus is (512 ~ 2048)

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

........................++++++

...................++++++

..++++++++

............++++++++

Create the key pair successfully.

# Generate a DSA key pair.

[Switch] public-key local create dsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

.++++++++++++++++++++++++++++++++++++++++++++++++++*

........+......+.....+......................................+

...+.................+..........+...+

Create the key pair successfully.

# Generate an ECDSA key pair.

[Switch] public-key local create ecdsa secp256r1

Generating Keys...

Create the key pair successfully.

# Enable the Stelnet server.

[Switch] ssh server enable

# Assign an IP address to 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 lines.

[Switch] line vty 0 15

[Switch-line-vty0-15] authentication-mode scheme

[Switch-line-vty0-15] quit

# Import the peer public key from the file key.pub, and name it ackey.

[Switch] public-key peer ackey import sshkey key.pub

# Create an SSH user named client002. Specify the authentication method as publickey for the user. Assign the public key ackey to the user.

[Switch] ssh user client002 service-type stelnet authentication-type publickey assign publickey ackey

# Create a local device management user named client002.

[Switch] local-user client002 class manage

# Authorize local user client002 to use the SSH service.

[Switch-luser-manage-client002] service-type ssh

# Assign the network-admin user role to local user client002.

[Switch-luser-manage-client002] authorization-attribute user-role network-admin

[Switch-luser-manage-client002] quit

3. Establish an SSH connection to the Stelnet server.

<AC> ssh2 192.168.1.40

Username: client002

Press CTRL+C to abort.

Connecting to 192.168.1.40 port 22.

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

Do you want to save the server public key? [Y/N]:n

Enter a character ~ and a dot to abort.

******************************************************************************

* Without the owner's prior written consent, *

* no decompiling or reverse-engineering shall be allowed. *

******************************************************************************

Select Yes to access the server and download the server's host public key. At the next connection attempt, the client authenticates the server by using the saved server's host public key on the client.

SFTP configuration examples

Password authentication enabled SFTP server configuration example

Network requirements

As shown in Figure 109:

· AC 2 acts as the SFTP server and uses password authentication.

· The username and password of AC 1 are saved on AC 2.

Establish an SFTP connection between AC 1 and AC 2, so you can log in to AC 2 to manage and transfer files.

Figure 109 Network diagram

Configuration procedure

1. Configure the SFTP server:

# Generate RSA key pairs.

<AC2> system-view

[AC2] public-key local create rsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

........................++++++

...................++++++

..++++++++

............++++++++

Create the key pair successfully.

# Generate a DSA key pair.

[AC2] public-key local create dsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

.++++++++++++++++++++++++++++++++++++++++++++++++++*

........+......+.....+......................................+

...+.................+..........+...+

Create the key pair successfully.

# Generate an ECDSA key pair.

[AC2] public-key local create ecdsa secp256r1

Generating Keys...

Create the key pair successfully.

# Enable the SFTP server.

[AC2] sftp server enable

# Assign an IP address to VLAN-interface 2. The client uses this address as the destination for SSH connection.

[AC2] interface vlan-interface 2

[AC2-Vlan-interface2] ip address 192.168.1.45 255.255.255.0

[AC2-Vlan-interface2] quit

# Create a local device management user named client002.

[AC2] local-user client002 class manage

# Set the password to aabbcc in plain text for local user client002.

[AC2-luser-manage-client002] password simple aabbcc

# Authorize local user client002 to use the SSH service.

[AC2-luser-manage-client002] service-type ssh

# Assign the network-admin user role and working directory cfa0:/ to local user client002.

[AC2-luser-manage-client002] authorization-attribute user-role network-admin work-directory cfa0:/

[AC2-luser-manage-client002] quit

# Create an SSH user named client002. Specify the authentication method as password and service type as sftp for the user.

[AC2] ssh user client002 service-type sftp authentication-type password

2. Establish a connection between the SFTP client and the SFTP server:

The device supports different types of SFTP client software. This example uses an SFTP client that runs PSFTP of PuTTy version 0.58.

NOTE:

PSFTP supports only password authentication.

To establish a connection to the SFTP server:

a. Run the psftp.exe to launch the client interface shown in Figure 110, and enter the following command:

open 192.168.1.45

b. Enter username client002 and password aabbcc as prompted to log in to the SFTP server.

Figure 110 SFTP client interface

Publickey authentication enabled SFTP client configuration example

Network requirements

As shown in Figure 111, AC 2 acts as the SFTP server, and it uses publickey authentication and the RSA public key algorithm.

Establish an SFTP connection between AC 1 and AC 2, so you can log in to AC 2 to manage and transfer files.

Figure 111 Network diagram

Configuration procedure

In the server configuration, the client's host public key is required. Generate RSA key pairs on the client before configuring the SFTP server.

1. Configure the SFTP client:

# Assign an IP address to VLAN-interface 2.

<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

# Generate RSA key pairs.

[AC1] public-key local create rsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

........................++++++

...................++++++

..++++++++

............++++++++

Create the key pair successfully.

# Export the host public key to the file pubkey.

[AC1] public-key local export rsa ssh2 pubkey

[AC1] quit

# Transmit the public key file pubkey to the server through FTP or TFTP. (Details not shown.)

2. Configure the SFTP server:

# Generate RSA key pairs.

<AC2> system-view

[AC2] public-key local create rsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

........................++++++

...................++++++

..++++++++

............++++++++

Create the key pair successfully.

# Generate a DSA key pair.

[AC2] public-key local create dsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

.++++++++++++++++++++++++++++++++++++++++++++++++++*

........+......+.....+......................................+

...+.................+..........+...+

Create the key pair successfully.

# Generate an ECDSA key pair.

[AC2] public-key local create ecdsa secp256r1

Generating Keys...

Create the key pair successfully.

# Enable the SFTP server.

[AC2] sftp server enable

# Assign an IP address to VLAN-interface 2. The SSH client uses this address as the destination 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

# Import the peer public key from the file pubkey, and name it ackey.

[AC2] public-key peer ackey import sshkey pubkey

# Create an SSH user named client001. Specify the service type as sftp and the authentication method as publickey for the user. Assign the public key ackey to the user.

[AC2] ssh user client001 service-type sftp authentication-type publickey assign publickey ackey

# Create a local device management user named client001.

[AC2] local-user client001 class manage

# Authorize local user client001 to use the SSH service.

[AC2-luser-manage-client001] service-type ssh

# Assign the network-admin user role and working directory cfa0:/ to local user client001.

[AC2-luser-manage-client001] authorization-attribute user-role network-admin work-directory cfa0:/

[AC2-luser-manage-client001] quit

3. Establish a connection to the SFTP server:

# Establish a connection to the SFTP server and enter SFTP client view.

<AC1> sftp 192.168.0.1 identity-key rsa

Username: client001

Press CTRL+C to abort.

Connecting to 192.168.0.1 port 22.

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

Do you want to save the server public key? [Y/N]:n

sftp>

# Display files under the current directory of the server, delete the file z, and verify the result.

sftp> dir -l

-rwxrwxrwx 1 noone nogroup 1759 Aug 23 06:52 config.cfg

-rwxrwxrwx 1 noone nogroup 225 Aug 24 08:01 pubkey2

-rwxrwxrwx 1 noone nogroup 283 Aug 24 07:39 pubkey

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

sftp> delete z

Removing /z

sftp> dir -l

-rwxrwxrwx 1 noone nogroup 1759 Aug 23 06:52 config.cfg

-rwxrwxrwx 1 noone nogroup 225 Aug 24 08:01 pubkey2

-rwxrwxrwx 1 noone nogroup 283 Aug 24 07:39 pubkey

drwxrwxrwx 1 noone nogroup 0 Sep 01 06:22 new

-rwxrwxrwx 1 noone nogroup 225 Sep 01 06:55 pub

# Add a directory new1 and verify the result.

sftp> mkdir new1

sftp> dir -l

-rwxrwxrwx 1 noone nogroup 1759 Aug 23 06:52 config.cfg

-rwxrwxrwx 1 noone nogroup 225 Aug 24 08:01 pubkey2

-rwxrwxrwx 1 noone nogroup 283 Aug 24 07:39 pubkey

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

# Rename directory new1 to new2 and verify the result.

sftp> rename new1 new2

sftp> dir -l

-rwxrwxrwx 1 noone nogroup 1759 Aug 23 06:52 config.cfg

-rwxrwxrwx 1 noone nogroup 225 Aug 24 08:01 pubkey2

-rwxrwxrwx 1 noone nogroup 283 Aug 24 07:39 pubkey

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

# Download the file pubkey2 from the server and save it as a local file public.

sftp> get pubkey2 public

Fetching / pubkey2 to public

/pubkey2 100% 225 1.4KB/s 00:00

# Upload the local file pu to the server, save it as puk, and verify the result.

sftp> put pu puk

Uploading pu to / puk

sftp> dir -l

-rwxrwxrwx 1 noone nogroup 1759 Aug 23 06:52 config.cfg

-rwxrwxrwx 1 noone nogroup 225 Aug 24 08:01 pubkey2

-rwxrwxrwx 1 noone nogroup 283 Aug 24 07:39 pubkey

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

sftp>

# Exit SFTP client view.

sftp> quit

<AC1>

SCP configuration example

Network requirements

As shown in Figure 112:

· AC 2 uses the password authentication method.

· The client's username and password are saved on AC 2.

Establish an SCP connection between AC 1 and AC 2, so you can log in to AC 2 to transfer files.

Figure 112 Network diagram

Configuration procedure

1. Configure the SCP server:

# Generate RSA key pairs.

<AC2> system-view

[AC2] public-key local create rsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

........................++++++

...................++++++

..++++++++

............++++++++

Create the key pair successfully.

# Generate a DSA key pair.

[AC2] public-key local create dsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

.++++++++++++++++++++++++++++++++++++++++++++++++++*

........+......+.....+......................................+

...+.................+..........+...+.

Create the key pair successfully.

# Generate an ECDSA key pair.

[AC2] public-key local create ecdsa secp256r1

Generating Keys...

Create the key pair successfully.

# Enable the SCP server.

[AC2] scp server enable

# Configure an IP address for VLAN-interface 2. The client uses this address as the destination 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

# Create a local device management user named client001.

[AC2] local-user client001 class manage

# Set the password to aabbcc in plain text for local user client001.

[AC2-luser-manage-client001] password simple aabbcc

# Authorize local user client001 to use the SSH service.

[AC2-luser-manage-client001] service-type ssh

# Assign the network-admin user role to local user client001.

[AC2-luser-manage-client001] authorization-attribute user-role network-admin

[AC2-luser-manage-client001] quit

# Create an SSH user named client001. Specify the service type as scp and the authentication method as password for the user.

[AC2] ssh user client001 service-type scp authentication-type password

2. Configure an IP address for VLAN-interface 2 on the SCP client.

<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

Press CTRL+C to abort.

Connecting to 192.168.0.1 port 22.

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

Do you want to save the server public key? [Y/N]:n

client001@192.168.0.1’s password:

remote.bin 100% 2875 2.8KB/s 00:00

NETCONF over SSH configuration example

Network requirements

As shown in Figure 113:

· AC 2 uses local password authentication.

· The client's username and password are saved on AC 2.

Establish a NETCONF-over-SSH connection between AC 1 and AC 2, so that you can log in to AC 2 to perform NETCONF operations.

Figure 113 Network diagram

Configuration procedure

# Generate RSA key pairs.

<AC2> system-view

[AC2] public-key local create rsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

........................++++++

...................++++++

..++++++++

............++++++++

Create the key pair successfully.

# Generate a DSA key pair.

[AC2] public-key local create dsa

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512, it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

.++++++++++++++++++++++++++++++++++++++++++++++++++*

........+......+.....+......................................+

...+.................+..........+...+.

Create the key pair successfully.

# Generate an ECDSA key pair.

[AC2] public-key local create ecdsa secp256r1

Generating Keys...

Create the key pair successfully.

# Enable NETCONF over SSH.

[AC2] netconf ssh server enable

# Configure an IP address for VLAN-interface 2. The client uses this address as the destination for NETCONF-over-SSH connection.

[AC2] interface vlan-interface 2

[AC2-Vlan-interface2] ip address 192.168.1.40 255.255.255.0

[AC2-Vlan-interface2] quit

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

[AC2] line vty 0 15

[AC2-line-vty0-15] authentication-mode scheme

[AC2-line-vty0-15] quit

# Create a local device management user named client001.

[AC2] local-user client001 class manage

# Set the password to aabbcc in plain text for local user client001.

[AC2-luser-manage-client001] password simple aabbcc

# Authorize local user client001 to use the SSH service.

[AC2-luser-manage-client001] service-type ssh

# Assign the network-admin user role to local user client001.

[AC2-luser-manage-client001] authorization-attribute user-role network-admin

[AC2-luser-manage-client001] quit

# Create an SSH user named client001. Specify the service type as NETCONF and the authentication method as password for the user.

[AC2] ssh user client001 service-type netconf authentication-type password

Verifying the configuration

1. Launch a client that supports NETCONF over SSH.

This example uses NetConf Browser 2015 (version 3.1).

2. Select File > Connect… from the menu.

The Connect page appears, as shown in Figure 114.

3. Configure connection parameters as follows:

a. Select a connection type from the Connection type list.

This example uses SSH2-ganymed.

b. Select 1.0 from the NETCONF version list.

c. Enter 192.168.100.49 in the Host field.

d. Enter 830 in the Port field.

e. Enter client001 in the Username field.

f. Use the default setting for the Public Key Authentication area.

4. Click Connect.

Figure 114 Connecting to the device

5. Enter password aabbcc, and then click OK, as shown in Figure 115.

Figure 115 Entering the password

The NETCONF configuration interface appears when the client successfully establishes an NETCONF-over-SSH connection to the device. The Log tab of the interface displays the connection information, as shown in Figure 116.

Figure 116 Logging in to the device

6. In the Command XML area of the NETCONF configuration interface, enter <get-sessions/>, and then click Send.

The following message is displayed in the Output XML area.

<?xml version="1.0" encoding="utf-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">

<get-sessions>

<UserName>client001</UserName>

<LockHeld>false</LockHeld>

</Session>

</get-sessions>

</rpc-reply>

Configuring SSL

Overview

Secure Sockets Layer (SSL) is a cryptographic protocol that provides communication security for TCP-based application layer protocols such as HTTP. SSL has been widely used in applications such as e-business and online banking to provide secure data transmission over the Internet.

SSL security services

SSL provides the following security services:

· Privacy—SSL uses a symmetric encryption algorithm to encrypt data. It uses the asymmetric key algorithm of RSA to encrypt the key used by the symmetric encryption algorithm. For more information about RSA, see "Managing public keys."

· Authentication—SSL uses certificate-based digital signatures to authenticate the SSL server and client. The SSL server and client obtain digital certificates through PKI. For more information about PKI and digital certificates, see "Configuring PKI."

· Integrity—SSL uses the message authentication code (MAC) to verify message integrity. It uses a MAC algorithm and a key to transform a message of any length to a fixed-length message. Any change to the original message will result in a change to the calculated fixed-length message. As shown in Figure 117, the message integrity verification process is as follows:

a. The sender uses a MAC algorithm and a key to calculate a MAC value for a message. Then, it appends the MAC value to the message and sends the message to the receiver.

b. The receiver uses the same key and MAC algorithm to calculate a MAC value for the received message, and compares it with the MAC value appended to the message.

c. If the two MAC values match, the receiver considers the message intact. Otherwise, the receiver considers that the message was tampered with and it discards the message.

Figure 117 MAC algorithm diagram

SSL protocol stack

The SSL protocol stack includes the following protocols:

· SSL record protocol at the lower layer.

· SSL handshake protocol, SSL change cipher spec protocol, and SSL alert protocol at the upper layer.

Figure 118 SSL protocol stack

The following describes the major functions of SSL protocols:

· SSL record protocol—Fragments data received from the upper layer, computes and adds MAC to the data, and encrypts the data.

· SSL handshake protocol—Negotiates the cipher suite used for secure communication, authenticates the server and client, and securely exchanges the keys between the server and client. The cipher suite that needs to be negotiated includes the symmetric encryption algorithm, key exchange algorithm, and MAC algorithm.

· SSL change cipher spec protocol—Notifies the receiver that subsequent packets are to be protected based on the negotiated cipher suite and key.

· SSL alert protocol—Sends alert messages to the receiving party. An alert message contains the alert severity level and a description.

SSL configuration task list

Tasks at a glance	Remarks
Configuring an SSL server policy	Perform this configuration task on the SSL server.
Configuring an SSL client policy	Perform this configuration task on the SSL client.

Configuring an SSL server policy

An SSL server policy is a set of SSL parameters used by the SSL server. 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). By default, the SSL server can communicate with clients running SSL 3.0 or TLS 1.0. When the server receives an SSL 2.0 Client Hello message from a client that supports both SSL 2.0 and SSL 3.0/TLS 1.0, it notifies the client to use SSL 3.0 or TLS 1.0 for communication.

You can disable SSL 3.0 on the device to enhance system security.

To configure an SSL server policy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. (Optional.) Disable SSL 3.0.	ssl version ssl3.0 disable	By default, SSL 3.0 is enabled.
3. (Optional.) Disable SSL session renegotiation for the SSL server.	ssl renegotiation disable	By default, SSL session renegotiation is enabled.
4. Create an SSL server policy and enter its view.	ssl server-policy policy-name	By default, no SSL server policies exist on the device.
5. (Optional.) Specify a PKI domain for the SSL server policy.	pki-domain domain-name	By default, no PKI domain is specified for an SSL server policy. If SSL server authentication is required, you must specify a PKI domain and request a local certificate for the SSL server in the domain. For information about how to create and configure a PKI domain, see "Configuring PKI."
6. Specify the cipher suites that the SSL server policy supports.	ciphersuite { dhe_rsa_aes_128_cbc_sha \| exp_rsa_des_cbc_sha \| exp_rsa_rc2_md5 \| exp_rsa_rc4_md5 \| 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 } *	By default, an SSL server policy supports all cipher suites.
7. Set the maximum number of sessions that the SSL server can cache and the session cache timeout time.	session { cachesize size \| timeout time }	By default, the SSL server can cache a maximum of 500 sessions, and the session cache timeout time is 3600 seconds.
8. (Optional.) Enable mandatory or optional SSL client authentication.	client-verify { enable \| optional }	By default, SSL client authentication is disabled. The SSL server does not perform digital certificate-based authentication on SSL clients. When authenticating a client by using the digital certificate, the SSL server verifies the certificate chain presented by the client. It also verifies that the certificates in the certificate chain (except the root CA certificate) are not revoked.
9. (Optional.) Enable the SSL server to send the complete certificate chain to the client during SSL negotiation.	certificate-chain-sending enable	By default, the SSL server sends the server certificate rather than the complete certificate chain to the client during negotiation,

Configuring an SSL client policy

An SSL client policy is a set of SSL parameters that the client uses to establish a connection to the server. An SSL client policy takes effect only after it is associated with an application such as DDNS. For information about DDNS, see Layer 3—IP Services Configuration Guide.

You can specify the SSL version (SSL 3.0 or TLS 1.0) for an SSL client policy:

· If TLS 1.0 is specified and SSL 3.0 is not disabled, the client first uses TLS 1.0 to connect to the SSL server. If the connection attempt fails, the client uses SSL 3.0.

· If TLS 1.0 is specified and SSL 3.0 is disabled, the client only uses TLS 1.0 to connect to the SSL server.

· If SSL 3.0 is specified, the client uses SSL 3.0 to connect to the SSL server, whether you disable SSL 3.0 or not.

As a best practice to enhance system security, disable SSL 3.0 on the device and specify TLS 1.0 for an SSL client policy.

To configure an SSL client policy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. (Optional.) Disable SSL 3.0.	ssl version ssl3.0 disable	By default, SSL 3.0 is enabled.
3. (Optional.) Disable SSL session renegotiation for the SSL client.	ssl renegotiation disable	By default, SSL session renegotiation is enabled.
4. Create an SSL client policy and enter its view.	ssl client-policy policy-name	By default, no SSL client policies exist on the device.
5. (Optional.) Specify a PKI domain for the SSL client policy.	pki-domain domain-name	By default, no PKI domain is specified for an SSL client policy. If SSL client authentication is required, you must specify a PKI domain and request a local certificate for the SSL client in the PKI domain. For information about how to create and configure a PKI domain, see "Configuring PKI."
6. Specify the preferred cipher suite for the SSL client policy.	prefer-cipher { dhe_rsa_aes_128_cbc_sha \| dhe_rsa_aes_256_cbc_sha \| exp_rsa_des_cbc_sha \| exp_rsa_rc2_md5 \| exp_rsa_rc4_md5 \| 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 }	The default preferred cipher suite is rsa_rc4_128_md5.
7. Specify the SSL version for the SSL client policy.	version { ssl3.0 \| tls1.0 }	By default, an SSL client policy uses TLS 1.0.
8. Enable the SSL client to authenticate servers through digital certificates.	server-verify enable	By default, SSL server authentication is enabled.

Displaying and maintaining SSL

Execute display commands in any view.

Task	Command
Display SSL server policy information.	display ssl server-policy [ policy-name ]
Display SSL client policy information.	display ssl client-policy [ policy-name ]

SSL server policy configuration example

Network requirements

As shown in Figure 119, users need to access and manage the AC through the Web page.

To protect the AC and prevent data from being eavesdropped or tampered with, configure the AC to be accessible through HTTPS only.

In this example, the CA server runs Windows Server and has the SCEP plug-in installed.

Figure 119 Network diagram

Configuration considerations

To meet the network requirements, perform the following tasks:

· Configure the AC as the HTTPS server and request a server certificate for the AC. For more information about HTTPS, see Fundamentals Configuration Guide.

· Request a client certificate for the client so that the AC can authenticate the identity of the client.

Configuration procedure

1. Make sure the AC, the client, and the CA server can reach each other. (Details not shown.)

2. Configure the HTTPS server on the AC:

# Create a PKI entity named en. Set the common name and FQDN for the entity.

<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 PKI domain 1 and specify the name of the trusted CA as CA server. Set the URL of the registration server to http://10.1.2.2/certsrv/mscep/mscep.dll, the authority for certificate request to RA, and the entity for certificate request to en. Set the URL of the CRL repository to http://10.1.2.2/CertEnroll/caserver.crl.

[AC] pki domain 1

[AC-pki-domain-1] ca identifier CA server

[AC-pki-domain-1] certificate request url http://10.1.2.2/certsrv/mscep/mscep.dll

[AC-pki-domain-1] certificate request from ra

[AC-pki-domain-1] certificate request entity en

[AC-pki-domain-1] crl url http://10.1.2.2/CertEnroll/caserver.crl

# Configure a general-purpose RSA key pair named abc and set the key modulus length to 1024 bits.

[AC-pki-domain-1] public-key rsa general name abc length 1024

[AC-pki-domain-1] quit

# Generate the RSA key pair named abc.

[AC] public-key local create rsa name abc

The range of public key modulus is (512 ~ 2048).

If the key modulus is greater than 512,it will take a few minutes.

Press CTRL+C to abort.

Input the modulus length [default = 1024]:

Generating Keys...

..........................++++++

.....................................++++++

Create the key pair successfully.

# Obtain the CA certificate.

[AC] pki retrieve-certificate domain 1 ca

The trusted CA's finger print is:

MD5 fingerprint:7682 5865 ACC2 7B16 6F52 D60F D998 4484

SHA1 fingerprint:DF6B C53A E645 5C81 D6FC 09B0 3459 DFD1 94F6 3DDE

Is the finger print correct?(Y/N):y

Retrieved the certificates successfully.

# Request a certificate the AC.

[AC] pki request-certificate domain 1

Start to request general certificate ...

Certificate requested successfully.

# Create an SSL server policy named myssl.

[AC] ssl server-policy myssl

# Specify PKI domain 1 for the SSL server policy.

[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

# Configure the HTTPS service to use SSL server policy myssl.

[AC] ip https ssl-server-policy myssl

# Enable the HTTPS service.

[AC] ip https enable

# Create a local user named usera. Set the password to 123, service type to https, and user role to network-admin.

[AC] local-user usera

[AC-luser-usera] password simple 123

[AC-luser-usera] service-type https

[AC-luser-usera] authorization-attribute user-role network-admin

3. Request a certificate for the client:

a. Launch IE on the client, and then enter http://10.1.2.2/certsrv in the address bar.

b. Request a client certificate for the client. (Details not shown.)

Verifying the configuration

Perform the following tasks on the client:

1. Launch IE and enter https://10.1.1.1 in the address bar.

2. Select the client certificate issued by the CA server.

The login page of the AC should appear.

3. Enter username usera and password 123.

Verify that now you can log in to the Web interface to access and manage the AC.

Managing sessions

Overview

Session management is a common module, providing basic services for NAT, ASPF, and intrusion detection and protection to implement their session-based services. Session management can be applied for the following purposes:

· Fast match between packets and sessions.

· Management of transport layer protocol states.

· Identification of application layer protocols.

· Session aging based on protocol states or application layer protocols.

· Persistent sessions.

· Special packet match for the application layer protocols requiring port negotiation.

· ICMP/ICMPv6 error control packet resolution and session match based on the resolution results.

Session management operation

Session management tracks the session status by inspecting the transport layer protocol information. It updates session states or ages out sessions according to data flows from the initiators or responders.

When a connection request passes through the device from a client to a server, the device creates a session entry. The entry can contain the request and response information, such as:

· Source IP address and port number.

· Destination IP address and port number.

· Transport layer protocol.

· Application layer protocol.

· Protocol state of the session.

A multichannel protocol requires that the client and the server negotiate a new connection based on an existing connection to implement an application. Session management enables the device to create a relation entry for each connection during the negotiation phase. The entry is used to associate the connection with the application. Relation entries will be removed after the associated connections are established.

If the destination IP address of a packet is a multicast IP address, the packet will be forwarded out of multiple ports. When a multicast connection request is received on an inbound interface, the device performs the following operations:

· Creates a multicast session entry on the inbound interface.

· Creates a corresponding multicast session entry for each outbound interface.

Unless otherwise stated, "session entry" in this chapter refers to both unicast and multicast session entries.

In actual applications, session management works with ASPF to dynamically determine whether a packet can pass the firewall and enter the internal network according to connection status, thus preventing intrusion.

Session management only tracks connection status. It does not block potential attack packets.

Session management functions

Session management enables the device to provide the following functions:

· Creates sessions for protocol packets, updates session states, and sets aging time for sessions in different protocol states.

· Supports ICMP/ICMPv6 error packet mapping, enabling the device to search for original sessions according to the payloads in the ICMP/ICMPv6 error packets.

Because error packets are generated due to host errors, the mapping can help speed up the aging of the original sessions.

· Supports persistent sessions, which are kept alive for a long period of time.

· Supports session management for the control channels and dynamic data channels of application layer protocols, for example, FTP.

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

Session management task list

Tasks at a glance
(Optional.) Setting the session aging time for different protocol states
(Optional.) Specifying persistent sessions
(Optional.) Enabling session statistics collection
(Optional.) Specifying the loose mode for session state machine
(Optional.) Configuring session logging

Except for configuring session logging, all other tasks are mutually independent and can be configured in any order.

Setting the session aging time for different protocol states

IMPORTANT:

If more than 800000 sessions exist, do not set the aging time shorter than the default for a certain protocol state. Short aging time settings can make the device slow in response.

If a session in a certain protocol state has no packet hit before the aging time expires, the device automatically removes the session.

To set the session aging time for different protocol states:

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Set the session aging time for different protocol states.

session aging-time state { fin | icmp-reply | icmp-request | rawip-open | rawip-ready | syn | tcp-close | tcp-est | tcp-time-wait | udp-open | udp-ready } time-value

The default aging time for sessions in different protocol states is as follows:

· FIN_WAIT: 30 seconds.

· ICMP-REPLY: 30 seconds.

· ICMP-REQUEST: 60 seconds.

· RAWIP-OPEN: 30 seconds.

· RAWIP-READY: 60 seconds.

· TCP SYN-SENT and SYN-RCV: 30 seconds.

· TCP CLOSE: 2 seconds.

· TCP ESTABLISHED: 3600 seconds.

· TCP TIME-WAIT: 2 seconds.

· UDP-OPEN: 30 seconds.

· UDP-READY: 60 seconds.

Specifying persistent sessions

This task is only for TCP sessions in ESTABLISHED state. You can specify TCP sessions that match the permit statements in the specified ACL as persistent sessions, and set longer lifetime or never-age-out persistent sessions. A never-age-out session is not removed until the device receives a connection close request from the initiator or responder, or you manually clear the session entries.

For a TCP session in ESTABLISHED state, the priority order of the associated aging time is as follows:

· Aging time for persistent sessions.

· Aging time for sessions in different protocol states.

The system supports using multiple ACLs to specify persistent sessions.

To specify persistent sessions:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Specify persistent sessions.	session persistent acl [ ipv6 ] acl-number [ aging-time time-value ]	By default, no persistent sessions are specified.

Enabling session statistics collection

This feature enables the device to collect session-based outbound and inbound packets and bytes. You can display session statistics based on different criteria.

· To display statistics per unicast session, use the display session table command.

· To display statistics per unicast packet type, use the display session statistics command.

· To display statistics per multicast session, use the display session table multicast command.

· To display statistics per multicast packet type, use the display session statistics multicast command.

To enable session statistics collection:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable session statistics collection.	session statistics enable	By default, session statistics collection is disabled.

Specifying the loose mode for session state machine

For asymmetric-path networks, if session synchronization is not enabled, to prevent the device from dropping packets abnormally, set the mode of the session state machine to loose.

As a best practice, use the default strict mode on symmetric-path networks.

To specify the loose mode for session state machine:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Specify the loose mode for session state machine.	session state-machine mode loose	By default, session state machine is in strict mode.

Configuring session logging

Session logs provide information about user access, IP address translation, and network traffic for security auditing. These logs are sent to the log server or the information center.

The device supports time-based or traffic-based logging:

· Time-based logging—The device outputs session logs regularly.

· Traffic-based logging—The device outputs a session log when the traffic amount of a session reaches a threshold only when the session statistics collection feature is enabled. After outputting a session log, the device resets the traffic counter for the session. The traffic-based thresholds can be byte-based and packet-based. If you set both thresholds, the last configuration takes effect.

If you set both time-based and traffic-based logging, the device outputs a session log when whichever is reached. After outputting a session log, the device resets the traffic counter and restarts the interval for the session.

If you enable session logging but do not enable logging for session creation or deletion, the device does not output a session log when a session entry is created or removed.

The session logging feature must work with the flow log feature to generate session logs. For information about flow log, see Network Management and Monitoring.

To configure session logging:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. (Optional.) Set a time-based logging type.	session log time-active time-value	By default, no threshold is set for time-based session logging.
3. (Optional.) Set a traffic-based logging type.	session log { bytes-active bytes-value \| packets-active packets-value }	By default, no threshold is set for traffic-based logging.
4. (Optional.) Enable logging for session creation.	session log flow-begin	By default, logging for session creation is disabled.
5. (Optional.) Enable logging for session deletion.	session log flow-end	By default, logging for session deletion is disabled.
6. Enter interface view.	interface interface-type interface-number	N/A
7. Enable session logging.	session log enable { ipv4 \| ipv6 } [ acl acl-number ] { inbound \| outbound }	By default, session logging is disabled.

NOTE:

To configure session logging, you must use a minimum of one command from the following commands:

· session log time-active.

· session log { bytes-active bytes-value | packets-active packets-value }.

· session log flow-begin.

· session log flow-end.

Displaying and maintaining session management

Execute display commands in any view and reset commands in user view.

Task	Command
Display the aging time for sessions in different protocol states.	display session aging-time state
Display IPv4 unicast session table entries.	display session table ipv4 [ slot slot-number ] [ source-ip start-source-ip [ end-source-ip ] ] [ destination-ip start-destination-ip [ end-destination-ip ] ] [ protocol { dccp \| icmp \| raw-ip \| sctp \| tcp \| udp \| udp-lite } ] [ source-port source-port ] [ destination-port destination-port ] [ verbose ]
Display IPv6 unicast session table entries.	display session table ipv6 [ slot slot-number ] [ source-ip start-source-ip [ end-source-ip ] ] [ destination-ip start-destination-ip [ end-destination-ip ] ] [ protocol { dccp \| icmpv6 \| raw-ip \| sctp \| tcp \| udp \| udp-lite } ] [ source-port source-port ] [ destination-port destination-port ] [ verbose ]
Display IPv4 unicast session statistics.	display session statistics ipv4 { source-ip source-ip \| destination-ip destination-ip \| protocol { dccp \| icmp \| raw-ip \| sctp \| tcp \| udp \| udp-lite } \| source-port source-port \| destination-port destination-port } * [ slot slot-number ]
Display IPv6 unicast session statistics.	display session statistics ipv6 { source-ip source-ip \| destination-ip destination-ip \| protocol { dccp \| icmpv6 \| raw-ip \| sctp \| tcp \| udp \| udp-lite } \| source-port source-port \| destination-port destination-port } * [ slot slot-number ]
Display summary information about unicast session statistics.	display session statistics [ summary ] [ slot slot-number ]
Display IPv4 multicast session table entries.	display session table multicast ipv4 [ slot slot-number ] [ source-ip start-source-ip [ end-source-ip ] ] [ destination-ip start-destination-ip [ end-destination-ip ] ] [ protocol { dccp \| icmp \| raw-ip \| sctp \| tcp \| udp \| udp-lite } ] [ source-port source-port ] [ destination-port destination-port ] [ verbose ]
Display IPv6 multicast session table entries.	display session table multicast ipv6 [ slot slot-number ] [ source-ip start-source-ip [ end-source-ip ] ] [ destination-ip start-destination-ip [ end-destination-ip ] ] [ protocol { dccp \| icmpv6 \| raw-ip \| sctp \| tcp \| udp \| udp-lite } ] [ source-port source-port ] [ destination-port destination-port ] [ verbose ]
Display multicast session statistics.	display session statistics multicast [ slot slot-number ]
Display relation table entries.	display session relation-table { ipv4 \| ipv6 } [ slot slot-number ]
Clear IPv4 unicast session table entries.	reset session table ipv4 [ slot slot-number ] [ source-ip source-ip ] [ destination-ip destination-ip ] [ protocol { dccp \| icmp \| raw-ip \| sctp \| tcp \| udp \| udp-lite } ] [ source-port source-port ] [ destination-port destination-port ] [ vpn-instance vpn-instance-name ]
Clear IPv6 unicast session table entries.	reset session table ipv6 [ slot slot-number ] [ source-ip source-ip ] [ destination-ip destination-ip ] [ protocol { dccp \| icmpv6 \| raw-ip \| sctp \| tcp \| udp \| udp-lite } ] [ source-port source-port ] [ destination-port destination-port ] [ vpn-instance vpn-instance-name ]
Clear IPv4 and IPv6 unicast session table entries.	reset session table [ slot slot-number ]
Clear unicast session statistics.	reset session statistics [ slot slot-number ]
Clear IPv4 multicast session table entries.	reset session table multicast ipv4 [ slot slot-number ] [ source-ip source-ip ] [ destination-ip destination-ip ] [ protocol { dccp \| icmp \| raw-ip \| sctp \| tcp \| udp \| udp-lite } ] [ source-port source-port ] [ destination-port destination-port ] [ vpn-instance vpn-instance-name ]
Clear IPv6 multicast session table entries.	reset session table multicast ipv6 [ slot slot-number ] [ source-ip source-ip ] [ destination-ip destination-ip ] [ protocol { dccp \| icmpv6 \| raw-ip \| sctp \| tcp \| udp \| udp-lite } ] [ source-port source-port ] [ destination-port destination-port ] [ vpn-instance vpn-instance-name ]
Clear IPv4 and IPv6 multicast session table entries.	reset session table multicast [ slot slot-number ]
Clear multicast session statistics.	reset session statistics multicast [ slot slot-number ]
Clear relation table entries.	reset session relation-table [ ipv4 \| ipv6 ] [ slot slot-number ]

Configuring connection limits

Overview

The connection limit feature enables the device to monitor and limit the number of established connections.

As shown in Figure 120, the following problems might exist:

· If Host B initiates a large number of connections in a short period of time, it might exhaust system resources and cause Host A to be unable to access the Internet.

· If the internal server receives a large number of connection requests in a short period of time, the server cannot process other requests.

Figure 120 Network diagram

To resolve these problems, configure connection limits on all interfaces or on an interface by applying the configured connection limit policies globally or to the interface.

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

Connection limit configuration task list

Tasks at a glance
(Required.) Creating a connection limit policy
(Required.) Configuring the connection limit policy
(Required.) Applying the connection limit policy

Creating a connection limit policy

A connection limit policy contains a set of connection limit rules, each of which defines a range of connections and the criteria for limiting the connections.

To create a connection limit policy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a connection limit policy and enter its view.	connection-limit { ipv6-policy \| policy } policy-id	By default, no connection limit policy exists.

Configuring the connection limit policy

To use a connection limit policy, you need to add limit rules to the policy. Each rule defines a range of connections and the criteria for limiting the connections. Connections in the range will be limited based on the criteria. The criteria include upper/lower connection limit and connection establishment rate limit. When the number of matching connections reaches the upper limit, the device does not accept new connections until the number of connections drops below the lower limit. The device will send logs when the number of connections exceeds the upper limit and when the number of connections drops below the lower limit. If the matching connections are limited based on the establishment rate, the number of connections established per second cannot exceed the rate limit. The connections that do not match any connection limit rules are not limited.

In each connection limit rule, an ACL is used to define the connection range. In addition, the rule also uses the following filtering methods to further limit the connections:

· per-destination—Limits user connections by destination IP address.

· per-service—Limits user connections by service (transport layer protocol and service port).

· per-source—Limits user connections by source IP address.

You can select more than one filtering method, and the selected methods take effect at the same time. For example, if you specify both per-destination and per-service, the user connections using the same service and destined to the same IP address are limited. If you do not specify any filtering methods in a limit rule, all user connections in the range are limited.

When a connection limit policy is applied, connections on the device match all limit rules in the policy in ascending order of rule IDs. H3C recommends that you specify a smaller range and more filtering methods in a rule with a smaller ID.

To configure the connection limit policy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter connection limit policy view.	connection-limit { ipv6-policy \| policy } policy-id	N/A
3. Configure a connection limit rule.	· In IPv4 connection limit policy view: limit limit-id acl { acl-number \| name acl-name } [ per-destination \| per-service \| per-source ] * { amount max-amount min-amount \| rate rate } * [ description text ] · In IPv6 connection limit policy view: limit limit-id acl ipv6 { acl-number \| name acl-name } [ per-destination \| per-service \| per-source ] * { amount max-amount min-amount \| rate rate } * [ description text ]	By default, no connection limit rules exist.
4. (Optional.) Configure a description for the connection limit policy.	description text	By default, the connection limit policy does not have a description.

Applying the connection limit policy

To make a connection limit policy take effect, apply it globally or to an interface. The connection limit policy applied to an interface takes effect only on the specified connections on the interface. The connection limit policy applied globally takes effect on all the specified connections on the device.

Different connection limit policies can be applied to individual interfaces as well as globally on the device. In this case, the device matches connections against these policies in the order of the policy on the inbound interface, the global policy, and the policy on the outbound interface. It cannot accept new connections as long as the number of connections reaches the lowest upper connection limit defined by these policies.

To apply a connection limit policy:

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Apply a connection limit policy.

· Apply a connection limit policy globally:
connection-limit apply global { ipv6-policy | policy } policy-id

· Apply a connection limit policy to an interface:

a. interface interface-type interface-number

b. connection-limit apply { ipv6-policy | policy } policy-id

By default, no connection limit is applied.

Only one IPv4 connection limit policy and one IPv6 connection limit policy can be applied globally or to an interface. A new IPv4 or IPv6 connection limit policy overwrites the old policy.

Displaying and maintaining connection limits

Execute display commands in any view and reset commands in user view.

Task	Command
Display the connection limit policy information.	display connection-limit { ipv6-policy \| policy } { all \| policy-id }
Display the connection limit statistics globally or on an interface.	display connection-limit statistics { global \| interface interface-type interface-number } [ slot slot-number ]
Display statistics about IPv6 connections matching connection limit rules globally or on an interface.	display connection-limit { ipv6-stat-nodes \| stat-nodes } { global \| interface interface-type interface-number } [ slot slot-number ] [ destination destination-ip \| service-port port-number \| source source-ip ] * [ count ]
Clear the connection limit statistics globally or on an interface.	reset connection-limit statistics { global \| interface interface-type interface-number } [ slot slot-number ]

Connection limit configuration example

Network requirements

As shown in Figure 121, all hosts access the Web server through the wireless network. To ensure the availability of the service resources, configure the AC to allow a maximum of 100 HTTP connections from each host to the Web server.

Figure 121 Network diagram

Configuration procedure

# Create ACL 3000 to permit HTTP requests to the Web server.

<AC> system-view

[AC] acl advanced 3000

[AC-acl-ipv4-adv-3000] rule permit tcp source 192.168.1.0 0.0.0.255 destination-port eq 80

[AC-acl-ipv4-adv-3000] quit

# Create connection limit policy 1.

[AC] connection-limit policy 1

# Configure connection limit rule 1 to permit a maximum of 100 connections from each host matching ACL 3000. When the number of connections exceeds 100, new connections cannot be established until the number drops below 50.

[AC-connection-limit-policy-1] limit 1 acl 3000 per-source amount 100 50

[AC-connection-limit-policy-1] quit

# Apply connection limit policy 1 globally.

[AC] connection-limit apply global policy 1

Verifying the configuration

# Display information about the connection limit policy.

[AC] display connection-limit policy 1

IPv4 connection limit policy 1 has been applied 1 times, and has 1 limit rules.

Limit rule list:

Policy Rule Stat Type HiThres LoThres rate ACL

-------------------------------------------------------------------------------

1 1 Src 100 50 0 3000

Application list:

Global

Troubleshooting connection limits

ACLs in the connection limit rules with overlapping segments

Symptom

A connection limit policy has two rules. Rule 1 sets the upper limit to 10 for the connections from each host on segment 192.168.0.0/24. Rule 2 sets the upper limit to 100 for the connections from 192.168.0.100/24.

<AC> system-view

[AC] acl basic 2001

[AC-acl-ipv4-basic-2001] rule permit source 192.168.0.0 0.0.0.255

[AC-acl-ipv4-basic-2001] quit

[AC] acl basic 2002

[AC-acl-ipv4-basic-2002] rule permit source 192.168.0.100 0

[AC-acl-ipv4-basic-2002] quit

[AC] connection-limit policy 1

[AC-connection-limit-policy-1] limit 1 acl 2001 per-destination amount 10 5

[AC-connection-limit-policy-1] limit 2 acl 2002 per-destination amount 100 10

As a result, the host at 192.168.0.100 can only initiate a maximum of 10 connections to the external network.

Solution

To resolve the problem:

1. Rearrange the two connection limit rules by exchanging their rule IDs.

2. If the problem persists, contact H3C Support.

Configuring attack detection and prevention

Overview

Attack detection and prevention enables a device to detect attacks by inspecting arriving packets, and to take prevention actions to protect a private network. Prevention actions include logging and packet dropping.

Attacks that the device can prevent

This section describes the attacks that the device can detect and prevent.

Single-packet attacks

Single-packet attacks are also known as malformed packet attacks. An attacker typically launches single-packet attacks by using the following methods:

· An attacker sends defective packets to a device, which causes the device to malfunction or crash.

· An attacker sends normal packets to a device, which interrupts connections or probes network topologies.

· An attacker sends a large number of forged packets to a target device, which consumes network bandwidth and causes denial of service (DoS).

Table 10 lists the single-packet attack types that the device can detect and prevent.

Table 10 Types of single-packet attacks

Single-packet attack	Description
ICMP redirect	An attacker sends ICMP redirect messages to modify the victim's routing table. The victim cannot forward packets correctly.
ICMP destination unreachable	An attacker sends ICMP destination unreachable messages to cut off the connections between the victim and its destinations.
ICMP type	A receiver responds to an ICMP packet according to its type. An attacker sends forged ICMP packets of a specific type to affect the packet processing of the victim.
ICMPv6 type	A receiver responds to an ICMPv6 packet according to its type. An attacker sends forged ICMPv6 packets of specific types to affect the packet processing of the victim.
Land	An attacker sends the victim a large number of TCP SYN packets, which contain the victim's IP address as the source and destination IP addresses. This attack exhausts the half-open connection resources on the victim, and locks the victim's system.
Large ICMP packet	An attacker sends large ICMP packets to crash the victim. Large ICMP packets can cause memory allocation error and crash the protocol stack.
Large ICMPv6 packet	An attacker sends large ICMPv6 packets to crash the victim. Large ICMPv6 packets can cause memory allocation error and crash the protocol stack.
IP options	An attacker sends IP datagrams in which the IP options are abnormal. This attack intends to probe the network topology. The target system will break down if it is incapable of processing error packets.
IP fragment	An attacker sends the victim an IP datagram with an offset smaller than 5, which causes the victim to malfunction or crash.
IP impossible packet	An attacker sends IP packets whose source IP address is the same as the destination IP address, which causes the victim to malfunction.
Tiny fragment	An attacker makes the fragment size small enough to force Layer 4 header fields into the second fragment. These fragments can pass the packet filtering because they do not hit any match.
Smurf	An attacker broadcasts an ICMP echo request to target networks. These requests contain the victim's IP address as the source IP address. Every receiver on the target networks will send an ICMP echo reply to the victim. The victim will be flooded with replies, and will be unable to provide services. Network congestion might occur.
TCP flag	An attacker sends packets with defective TCP flags to probe the operating system of the target host. Different operating systems process unconventional TCP flags differently. The target system will break down if it processes this type of packets incorrectly.
Traceroute	An attacker uses traceroute tools to probe the topology of the victim network.
WinNuke	An attacker sends Out-Of-Band (OOB) data to the TCP port 139 (NetBIOS) on the victim that runs Windows system. The malicious packets contain an illegal Urgent Pointer, which causes the victim's operating system to crash.
UDP bomb	An attacker sends a malformed UDP packet. The length value in the IP header is larger than the IP header length plus the length value in the UDP header. When the target system processes the packet, a buffer overflow can occur, which causes a system crash.
UDP Snork	An attacker sends a UDP packet with destination port 135 (the Microsoft location service) and source port 135, 7, or 19. This attack causes an NT system to exhaust its CPU.
UDP Fraggle	An attacker sends a large number of chargen packets with source UDP port 7 and destination UDP port 19 to a network. These packets use the victim's IP address as the source IP address. Replies will flood the victim, resulting in DoS.
Teardrop	An attacker sends a stream of overlapping fragments. The victim will crash when it tries to reassemble the overlapping fragments.
Ping of death	An attacker sends the victim an ICMP echo request larger than 65535 bytes that violates the IP protocol. When the victim reassembles the packet, a buffer overflow can occur, which causes a system crash.

Scanning attacks

Scanning is a preintrusion activity used to prepare for intrusion into a network. The scanning allows the attacker to find a way into the target network and to disguise the attacker's identity.

Attackers use scanning tools to probe a network, find vulnerable hosts, and discover services that are running on the hosts. Attackers can use the information to launch attacks.

The device can detect and prevent the IP sweep and port scan attacks. If an attacker performs port scanning from multiple hosts to the target host, distributed port scan attacks occur.

Flood attacks

An attacker launches a flood attack by sending a large number of forged requests to the victim in a short period of time. The victim is too busy responding to these forged requests to provide services for legal users, and a DoS attack occurs.

The device can detect and prevent the following types of flood attacks:

· SYN flood attack.

A SYN flood attacker exploits the TCP three-way handshake characteristics and makes the victim unresponsive to legal users. An attacker sends a large number of SYN packets with forged source addresses to a server. This causes the server to open a large number of half-open connections and respond to the requests. However, the server will never receive the expected ACK packets. The server is unable to accept new incoming connection requests because all of its resources are bound to half-open connections.

· ACK flood attack.

An ACK packet is a TCP packet only with the ACK flag set. Upon receiving an ACK packet from a client, the server must search half-open connections for a match.

An ACK flood attacker sends a large number of ACK packets to the server. This causes the server to be busy searching for half-open connections, and the server is unable to process packets for normal services.

· SYN-ACK flood attack.

Upon receiving a SYN-ACK packet, the server must search for the matching SYN packet it has sent. A SYN-ACK flood attacker sends a large number of SYN-ACK packets to the server. This causes the server to be busy searching for SYN packets, and the server is unable to process packets for normal services.

· FIN flood attack.

FIN packets are used to shut down TCP connections.

A FIN flood attacker sends a large number of forged FIN packets to a server. The victim might shut down correct connections, or be unable to provide services because it is busy searching for matching connections.

· RST flood attack.

RST packets are used to abort TCP connections when TCP connection errors occur.

An RST flood attacker sends a large number of forged RST packets to a server. The victim might shut down correct connections, or be unable to provide services because it is busy searching for matching connections.

· DNS flood attack.

The DNS server processes and replies all DNS queries that it receives.

A DNS flood attacker sends a large number of forged DNS queries. This attack consumes the bandwidth and resources of the DNS server, which prevents the server from processing and replying legal DNS queries.

· HTTP flood attack.

Upon receiving an HTTP GET request, the HTTP server performs complex operations, including character string searching, database traversal, data reassembly, and format switching. These operations consume a large amount of system resources.

An HTTP flood attacker sends a large number of HTTP GET requests that exceed the processing capacity of the HTTP server, which causes the server to crash.

· ICMP flood attack.

An ICMP flood attacker sends ICMP request packets, such as ping packets, to a host at a fast rate. Because the target host is busy replying to these requests, it is unable to provide services.

· ICMPv6 flood attack.

An ICMPv6 flood attacker sends ICMPv6 request packets, such as ping packets, to a host at a fast rate. Because the target host is busy replying to these requests, it is unable to provide services.

· UDP flood attack.

A UDP flood attacker sends UDP packets to a host at a fast rate. These packets consume a large amount of the target host's bandwidth, so the host cannot provide other services.

TCP fragment attack

An attacker launches TCP fragment attacks by sending attack TCP fragments defined in RFC 1858:

· First fragments in which the TCP header is smaller than 20 bytes.

· Non-first fragments with a fragment offset of 8 bytes (FO=1).

Typically, packet filter detects the source and destination IP addresses, source and destination ports, and transport layer protocol of the first fragment of a TCP packet. If the first fragment passes the detection, all subsequent fragments of the TCP packet are allowed to pass through.

Because the first fragment of attack TCP packets does not hit any match in the packet filter, the subsequent fragments can all pass through. After the receiving host reassembles the fragments, a TCP fragment attack occurs.

To prevent TCP fragment attacks, enable TCP fragment attack prevention to drop attack TCP fragments.

Login dictionary attack

The login dictionary attack is an automated process to attempt to log in by trying all possible passwords from a pre-arranged list of values (the dictionary). Multiple login attempts can occur in a short period of time.

You can configure the login delay feature to slow down the login dictionary attacks. This feature enables the device to delay accepting another login request after detecting a failed login attempt for a user.

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

Attack detection and prevention configuration task list

Tasks at a glance
(Required.) Configuring an attack defense policy: · (Required.) Creating an attack defense policy · (Required.) Perform at least one of the following tasks to configure attack detection: ? Configuring a single-packet attack defense policy ? Configuring a scanning attack defense policy ? Configuring a flood attack defense policy · (Optional.) Configuring attack detection exemption
(Required.) Perform at least one of the tasks to apply an attack defense policy: · Applying an attack defense policy to an interface · Applying an attack defense policy to the device
(Optional.) Disabling log aggregation for single-packet attack events
(Optional.) Configuring TCP fragment attack prevention
(Optional.) Enabling the login delay

Configuring an attack defense policy

Creating an attack defense policy

An attack defense policy can contain a set of attack detection and prevention configuration against multiple attacks.

To create an attack defense policy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an attack defense policy and enter its view.	attack-defense policy policy-name	By default, no attack defense policy exists.

Configuring a single-packet attack defense policy

Apply the single-packet attack defense policy to the interface that is connected to the external network.

Single-packet attack detection inspects incoming packets based on the packet signature. If an attack packet is detected, the device can take the following actions:

· Output logs (the default action).

· Drop attack packets.

You can also configure the device to not take any actions.

To configure a single-packet attack defense policy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Configure signature detection for single-packet attacks.	· signature detect { fraggle \| fragment \| impossible \| land \| large-icmp \| large-icmpv6 \| smurf \| snork \| tcp-all-flags \| tcp-fin-only \| tcp-invalid-flags \| tcp-null-flag \| tcp-syn-fin \| tiny-fragment \| traceroute \| udp-bomb \| winnuke } [ action { { drop \| logging } * \| none } ] · signature detect { ip-option-abnormal \| ping-of-death \| teardrop } action { drop \| logging } * · signature detect icmp-type { icmp-type-value \| address-mask-reply \| address-mask-request \| destination-unreachable \| echo-reply \| echo-request \| information-reply \| information-request \| parameter-problem \| redirect \| source-quench \| time-exceeded \| timestamp-reply \| timestamp-request } [ action { { drop \| logging } * \| none } ] · signature detect icmpv6-type { icmpv6-type-value \| destination-unreachable \| echo-reply \| echo-request \| group-query \| group-reduction \| group-report \| packet-too-big \| parameter-problem \| time-exceeded } [ action { { drop \| logging } * \| none } ] · signature detect ip-option { option-code \| internet-timestamp \| loose-source-routing \| record-route \| route-alert \| security \| stream-id \| strict-source-routing } [ action { { drop \| logging } * \| none } ]	By default, signature detection is not configured for single-packet attacks. You can configure signature detection for multiple single-packet attacks.
4. (Optional.) Set the maximum length of safe ICMP or ICMPv6 packets.	signature { large-icmp \| large-icmpv6 } max-length length	By default, the maximum length of safe ICMP or ICMPv6 packets is 4000 bytes. A large ICMP or ICMPv6 attack occurs if an ICMP or ICMPv6 packet larger than the specified length is detected.
5. (Optional.) Specify the actions against single-packet attacks of a specific level.	signature level { high \| info \| low \| medium } action { { drop \| logging } * \| none }	The default action is logging for single-packet attacks of the informational and low levels. The default actions are logging and drop for single-packet attacks of the medium and high levels.
6. (Optional.) Enable signature detection for single-packet attacks of a specific level.	signature level { high \| info \| low \| medium } detect	By default, signature detection is disabled for all levels of single-packet attacks.

Configuring a scanning attack defense policy

Apply a scanning attack defense policy to the interface that is connected to the external network.

Scanning attack detection inspects the incoming packet rate of connections to the target system. If a source initiates connections at a rate equal to or exceeding the pre-defined threshold, the device can take the following actions:

· Output logs.

· Drop subsequent packets from the IP address of the attacker.

To configure a scanning attack defense policy:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Configure scanning attack detection.	scan detect level { high \| low \| medium } action { drop \| logging } *	By default, scanning attack detection is not configured.

Configuring a flood attack defense policy

Apply a flood attack defense policy to the interface that is connected to the external network to protect internal servers.

Flood attack detection monitors the rate at which connections are initiated to the internal servers.

With flood attack detection enabled, the device is in attack detection state. When the packet sending rate to an IP address reaches the threshold, the device enters prevention state and takes the specified actions. When the rate is below the silence threshold (three-fourths of the threshold), the device returns to the attack detection state.

You can configure flood attack detection and prevention for a specific IP address. For non-specific IP addresses, the device uses the global attack prevention settings.

Configuring a SYN flood attack defense policy

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Enable global SYN flood attack detection.	syn-flood detect non-specific	By default, global SYN flood attack detection is disabled.
4. Set the global trigger threshold for SYN flood attack prevention.	syn-flood threshold threshold-value	The default setting is 1000.
5. Specify global actions against SYN flood attacks.	syn-flood action { drop \| logging } *	By default, no global action is specified for SYN flood attacks.
6. Configure IP address-specific SYN flood attack detection.	syn-flood detect { ip ip-address \| ipv6 ipv6-address } [ threshold threshold-value ] [ action { { drop \| logging } * \| none } ]	By default, IP address-specific SYN flood attack detection is not configured.

Configuring an ACK flood attack defense policy

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Enable global ACK flood attack detection.	ack-flood detect non-specific	By default, global ACK flood attack detection is disabled.
4. Set the global trigger threshold for ACK flood attack prevention.	ack-flood threshold threshold-value	The default setting is 1000.
5. Specify global actions against ACK flood attacks.	ack-flood action { drop \| logging } *	By default, no global action is specified for ACK flood attacks.
6. Configure IP address-specific ACK flood attack detection.	ack-flood detect { ip ip-address \| ipv6 ipv6-address } [ threshold threshold-value ] [ action { { drop \| logging } * \| none } ]	By default, IP address-specific ACK flood attack detection is not configured.

Configuring a SYN-ACK flood attack defense policy

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Enable global SYN-ACK flood attack detection.	syn-ack-flood detect non-specific	By default, global SYN-ACK flood attack detection is disabled.
4. Set the global trigger threshold for SYN-ACK flood attack prevention.	syn-ack-flood threshold threshold-value	The default setting is 1000.
5. Specify global actions against SYN-ACK flood attacks.	syn-ack-flood action { drop \| logging } *	By default, no global action is specified for SYN-ACK flood attacks.
6. Configure IP address-specific SYN-ACK flood attack detection.	syn-ack-flood detect { ip ip-address \| ipv6 ipv6-address } [ threshold threshold-value ] [ action { { drop \| logging } * \| none } ]	By default, IP address-specific SYN-ACK flood attack detection is not configured.

Configuring a FIN flood attack defense policy

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Enable global FIN flood attack detection.	fin-flood detect non-specific	By default, global FIN flood attack detection is disabled.
4. Set the global trigger threshold for FIN flood attack prevention.	fin-flood threshold threshold-value	The default setting is 1000.
5. Specify global actions against FIN flood attacks.	fin-flood action { drop \| logging } *	By default, no global action is specified for FIN flood attacks.
6. Configure IP address-specific FIN flood attack detection.	fin-flood detect { ip ip-address \| ipv6 ipv6-address } [ threshold threshold-value ] [ action { { drop \| logging } * \| none } ]	By default, IP address-specific FIN flood attack detection is not configured.

Configuring an RST flood attack defense policy

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Enable global RST flood attack detection.	rst-flood detect non-specific	By default, global RST flood attack detection is disabled.
4. Set the global trigger threshold for RST flood attack prevention.	rst-flood threshold threshold-value	The default setting is 1000.
5. Specify global actions against RST flood attacks.	rst-flood action { drop \| logging } *	By default, no global action is specified for RST flood attacks.
6. Configure IP address-specific RST flood attack detection.	rst-flood detect { ip ip-address \| ipv6 ipv6-address } [ threshold threshold-value ] [ action { { drop \| logging } * \| none } ]	By default, IP address-specific RST flood attack detection is not configured.

Configuring an ICMP flood attack defense policy

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Enable global ICMP flood attack detection.	icmp-flood detect non-specific	By default, global ICMP flood attack detection is disabled.
4. Set the global trigger threshold for ICMP flood attack prevention.	icmp-flood threshold threshold-value	The default setting is 1000.
5. Specify global actions against ICMP flood attacks.	icmp-flood action { drop \| logging } *	By default, no global action is specified for ICMP flood attacks.
6. Configure IP address-specific ICMP flood attack detection.	icmp-flood detect ip ip-address [ threshold threshold-value ] [ action { { drop \| logging } * \| none } ]	By default, IP address-specific ICMP flood attack detection is not configured.

Configuring an ICMPv6 flood attack defense policy

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Enable global ICMPv6 flood attack detection.	icmpv6-flood detect non-specific	By default, global ICMPv6 flood attack detection is disabled.
4. Set the global trigger threshold for ICMPv6 flood attack prevention.	icmpv6-flood threshold threshold-value	The default setting is 1000.
5. Specify global actions against ICMPv6 flood attacks.	icmpv6-flood action { drop \| logging } *	By default, no global action is specified for ICMPv6 flood attacks.
6. Configure IP address-specific ICMPv6 flood attack detection.	icmpv6-flood detect ipv6 ipv6-address [ threshold threshold-value ] [ action { { drop \| logging } * \| none } ]	By default, IP address-specific ICMPv6 flood attack detection is not configured.

Configuring a UDP flood attack defense policy

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Enable global UDP flood attack detection.	udp-flood detect non-specific	By default, global UDP flood attack detection is disabled.
4. Set the global trigger threshold for UDP flood attack prevention.	udp-flood threshold threshold-value	The default setting is 1000.
5. Specify global actions against UDP flood attacks.	udp-flood action { drop \| logging } *	By default, no global action is specified for UDP flood attacks.
6. Configure IP address-specific UDP flood attack detection.	udp-flood detect { ip ip-address \| ipv6 ipv6-address } [ threshold threshold-value ] [ action { { drop \| logging } * \| none } ]	By default, IP address-specific UDP flood attack detection is not configured.

Configuring a DNS flood attack defense policy

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Enable global DNS flood attack detection.	dns-flood detect non-specific	By default, global DNS flood attack detection is disabled.
4. Set the global trigger threshold for DNS flood attack prevention.	dns-flood threshold threshold-value	The default setting is 1000.
5. (Optional.) Specify the global ports to be protected against DNS flood attacks.	dns-flood port port-list	By default, DNS flood attack prevention protects port 53.
6. Specify global actions against DNS flood attacks.	dns-flood action { drop \| logging } *	By default, no global action is specified for DNS flood attacks.
7. Configure IP address-specific DNS flood attack detection.	dns-flood detect { ip ip-address \| ipv6 ipv6-address } [ port port-list ] [ threshold threshold-value ] [ action { { drop \| logging } * \| none } ]	By default, IP address-specific DNS flood attack detection is not configured.

Configuring an HTTP flood attack defense policy

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Enable global HTTP flood attack detection.	http-flood detect non-specific	By default, global HTTP flood attack detection is disabled.
4. Set the global trigger threshold for HTTP flood attack prevention.	http-flood threshold threshold-value	The default setting is 1000.
5. (Optional.) Specify the global ports to be protected against HTTP flood attacks.	http-flood port port-list	By default, HTTP flood attack prevention protects port 80.
6. Specify global actions against HTTP flood attacks.	http-flood action { drop \| logging } *	By default, no global action is specified for HTTP flood attacks.
7. Configure IP address-specific HTTP flood attack detection.	http-flood detect { ip ip-address \| ipv6 ipv6-address } [ port port-list ] [ threshold threshold-value ] [ action { { drop \| logging } * \| none } ]	By default, IP address-specific HTTP flood attack detection is not configured.

Configuring attack detection exemption

The attack defense policy uses the ACL to identify exempted packets. The policy does not check the packets permitted by the ACL. You can configure the ACL to identify packets from trusted servers. The exemption feature reduces the false alarm rate and improves packet processing efficiency.

If an ACL is used for attack detection exemption, only the following match criteria in the ACL permit rules take effect:

· Source IP address.

· Destination IP address.

· Source port.

· Destination port.

· Protocol.

· fragment keyword for matching non-first fragments.

To configure attack detection exemption:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter attack defense policy view.	attack-defense policy policy-name	N/A
3. Configure attack detection exemption.	exempt acl [ ipv6 ] { acl-number \| name acl-name }	By default, the attack defense policy applies to all incoming packets.

Applying an attack defense policy to an interface

An attack defense policy does not take effect unless you apply it to an interface.

If you apply an attack defense policy to a global interface, specify a service card to process traffic for the interface. If you do not specify a service card, the policy cannot correctly detect and prevent scanning and flood attacks.

To apply an attack defense policy to an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter system view.	interface interface-type interface-number	N/A
3. Apply an attack defense policy to the interface.	attack-defense apply policy policy-name	By default, no attack defense policy is applied to the interface.

Applying an attack defense policy to the device

An attack defense policy applied to the device itself rather than the interfaces detects packets destined for the device and prevents attacks targeted at the device.

If a device and its interfaces have attack defense policies applied, a packet destined for the device is processed as follows:

1. The policy applied to the receiving interface processes the packet.

2. If the packet is not dropped by the receiving interface, the policy applied to the device processes the packet.

To apply an attack defense policy to the device:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Apply an attack defense policy to the device.	attack-defense local apply policy policy-name	By default, no attack defense policy is applied to the device.

Disabling log aggregation for single-packet attack events

Log aggregation aggregates all logs generated in a period and sends one log. The logs with the same attributes for the following items can be aggregated:

· Interface where the attack is detected.

· Attack type.

· Attack defense action.

· Source and destination IP addresses.

H3C recommends that you not disable log aggregation. A large number of logs will consume the display resources of the console.

To disable log aggregation for single-packet attack events:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Disable log aggregation for single-packet attack events.	attack-defense signature log non-aggregate	By default, log aggregation is enabled for single-packet attack events.

Configuring TCP fragment attack prevention

The TCP fragment attack prevention feature detects the length and fragment offset of received TCP fragments and drops attack TCP fragments.

TCP fragment attack prevention takes precedence over single-packet attack prevention. When both are used, incoming TCP packets are processed first by TCP fragment attack prevention and then by the single-packet attack defense policy.

To configure TCP fragment attack prevention:

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Enable TCP fragment attack prevention.

attack-defense tcp fragment enable

By default, TCP fragment attack prevention is enabled.

TCP fragment attack prevention is typically used alone.

Enabling the login delay

The login delay feature delays the device to accept a login request from a user after the user fails a login attempt. This feature can slow down login dictionary attacks.

To enable the login delay:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the login delay feature.	attack-defense login reauthentication-delay seconds	By default, the login delay feature is disabled. The device does not delay accepting a login request from a user who has failed a login attempt.

Displaying and maintaining attack detection and prevention

Use the display commands in any view and the reset commands in user view.

To display and maintain attack detection and prevention:

Task	Command
Display attack detection and prevention statistics on an interface.	display attack-defense statistics interface interface-type interface-number [ slot slot-number ]
Display attack detection and prevention statistics for the device.	display attack-defense statistics local [ slot slot-number ]
Display attack defense policy configuration.	display attack-defense policy [ policy-name ]
Display information about IPv4 scanning attackers.	display attack-defense scan attacker ip [ interface interface-type interface-number [ slot slot-number ] \| local ] [ count ]
Display information about IPv6 scanning attackers.	display attack-defense scan attacker ipv6 [ interface interface-type interface-number [ slot slot-number ] \| local ] [ count ]
Display information about IPv4 scanning attack victims.	display attack-defense scan victim ip [ interface interface-type interface-number [ slot slot-number ] \| local ] [ count ]
Display information about IPv6 scanning attack victims.	display attack-defense scan victim ipv6 [ interface interface-type interface-number [ slot slot-number ] \| local ] [ count ]
Display flood attack detection and prevention statistics for an IPv4 address.	display attack-defense { ack-flood \| dns-flood \| fin-flood \| flood \| http-flood \| icmp-flood \| rst-flood \| syn-ack-flood \| syn-flood \| udp-flood } statistics ip [ ip-address ] [ interface interface-type interface-number [ slot slot-number ] \| local [ slot slot-number ] ] [ count ]
Display flood attack detection and prevention statistics for an IPv6 address.	display attack-defense { ack-flood \| dns-flood \| fin-flood \| flood \| http-flood \| icmpv6-flood \| rst-flood \| syn-ack-flood \| syn-flood \| udp-flood } statistics ipv6 [ ipv6-address ] [ interface interface-type interface-number [ slot slot-number ] \| local [ slot slot-number ] ] [ count ]
Display information about IPv4 addresses protected by flood attack detection and prevention.	display attack-defense policy policy-name { ack-flood \| dns-flood \| fin-flood \| flood \| http-flood \| icmp-flood \| rst-flood \| syn-ack-flood \| syn-flood \| udp-flood } ip [ ip-address ] [ slot slot-number ] [ count ]
Display information about IPv6 addresses protected by flood attack detection and prevention.	display attack-defense policy policy-name { ack-flood \| dns-flood \| fin-flood \| flood \| http-flood \| icmpv6-flood \| rst-flood \| syn-ack-flood \| syn-flood \| udp-flood } ipv6 [ ipv6-address ] [ slot slot-number ] [ count ]
Clear attack detection and prevention statistics for an interface.	reset attack-defense statistics interface interface-type interface-number
Clear attack detection and prevention statistics for the device.	reset attack-defense statistics local
Clear flood attack detection and prevention statistics.	reset attack-defense policy policy-name flood protected { ip \| ipv6 } statistics

Configuring IP source guard

Overview

IP source guard (IPSG) prevents spoofing attacks by using WLAN snooping entries to filter packets received by an AP. It drops packets that do not match the entries.

WLAN snooping is enabled by default on the AP. A WLAN snooping entry is an IP-MAC binding.

· In an IPv4 network, WLAN snooping reads the clients' IP-MAC bindings from the ARP messages or DHCP packets that pass through the AP. IPSG uses only the WLAN snooping entries obtained through DHCP packets.

· In an IPv6 network, WLAN snooping reads the clients' IP-MAC bindings from packets that pass through the AP. The packets are RA messages, NS messages, NA messages, and DHCP packets. IPSG uses all WLAN snooping entries for packet filtering.

For information about DHCP, DHCPv6, and ND, see Layer 3—IP Services Configuration Guide.

As shown in Figure 122, the AP has a WLAN snooping entry for the client that has obtained an IP address from the DHCP server. IPSG forwards packets only from the legal client.

Figure 122 IPSG application

Configuring the IPSG feature

IPSG enabled for a service template filters only packets from the clients in the BSSs created based on the service template. It does not affect clients in other BSSs.

To configure the IPSG feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-number	N/A
3. Enable the IPSG feature for IPv4.	ip verify source	By default, the IPSG feature is disabled for IPv4.
4. Enable the IPSG feature for IPv6.	ipv6 verify source	By default, the IPSG feature is disabled for IPv6.

Configuring the processing method for packets from unknown source IPv4 addresses

After you enable the IPSG feature on the AC, the IPv4 addresses learned from DHCP packets by APs are determined as known source IPv4 addresses. The following IPv4 addresses are unknown source IPv4 addresses:

· IPv4 addresses learned from ARP packets that pass through APs.

· IPv4 addresses that have not been learned by APs.

You can configure APs to process incoming packets from unknown source IPv4 addresses by using either of the following methods:

· Drop the packets only.

· Drop the packets and send deauthentication frames to the sources.

To configure the processing method for packets from unknown source IPv4 addresses received on APs:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-number	N/A
3. Configure the processing method for packets from unknown source IPv4 addresses received on APs.	ip verify unknown-ip { deauthenticate \| drop }	By default, APs drop packets from unknown source IPv4 addresses and send deauthentication frames to the sources.

IPSG configuration example

Network requirements

As shown in Figure 123, the clients access the WLAN through SSID service. Client 1 and Client 2 obtain IP addresses through the DHCP server (the switch).

Enable IPSG for the service template on the AC to make the AP filter incoming packets. The AP forwards the packets only from Client 1 and Client 2.

Figure 123 Network diagram

Configuration procedure

# Create service template 1.

<AC> system-view

[AC] wlan service-template 1

# Set the SSID to service for the service template, and enable the service template.

[AC-wlan-st-1] ssid service

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

# Enable the IPSG feature for IPv4.

[AC-wlan-st-1] ip verify source

[AC-wlan-st-1] quit

# Create the AP ap1 with the mode WA536-WW, and set its serial ID to 219801A1NQB117012935.

[AC] wlan ap ap1 model WA536-WW

[AC-wlan-ap-ap1] serial-id 219801A1NQB117012935

# Enter radio view of radio 2 and bind service template 1 to radio 2.

[AC-wlan-ap-ap1] radio 2

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

[AC-wlan-ap-ap1-radio-2] quit

[AC-wlan-ap-ap1] quit

Verifying the configuration

# Use Client 1 and Client 2 to obtain their IP addresses through DHCP, and manually assign Client 3 the IP address of Client 1. (Details not shown.)

# Verify that packets from Client 1 and Client 2 are allowed to pass. (Details not shown.)

# Verify that packets from client 3 are dropped. (Details not shown.)

Configuring ARP attack protection

Overview

ARP attacks and viruses are threatening LAN security. This chapter describes multiple features used to detect and prevent ARP attacks.

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 to have the receiving device busy with resolving IP addresses until its CPU is overloaded. Unresolvable IP packets refer to IP packets for which ARP cannot find corresponding MAC addresses.

· Sends a large number of ARP packets to overload the CPU of the receiving device.

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

ARP attack protection configuration task list

Tasks at a glance

Configuring flood prevention:

Configuring source MAC-based ARP attack detection (configured on gateways)

Configuring user and gateway spoofing prevention:

· Configuring ARP packet source MAC consistency check (configured on gateways)

· Configuring ARP active acknowledgement (configured on gateways)

· Configuring authorized ARP (configured on gateways)

· Configuring ARP attack detection (configured on access devices)

· Configuring ARP scanning and fixed ARP (configured on gateways)

· Configuring ARP gateway protection (configured on access devices)

· Configuring ARP filtering (configured on access devices)

Configuring source MAC-based ARP attack detection

This feature checks the number of ARP packets delivered to the CPU. If the number of packets from the same MAC address within 5 seconds exceeds a threshold, the device adds the MAC address to an ARP attack entry. Before the entry ages out, the device handles the attack by using either of the following methods:

· Monitor—Only generates log messages.

· Filter—Generates log messages and filters out subsequent ARP packets from that MAC address.

You can exclude the MAC addresses of some gateways and servers from this detection. This feature does not inspect ARP packets from those devices even if they are attackers.

Configuration procedure

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 source-mac { filter \| monitor }	By default, this feature is disabled. When you change the handling method from monitor to filter, the configuration takes effect immediately. When you change the handling method from filter to monitor, the device continues filtering packets that match existing attack entries.
3. Set the threshold.	arp source-mac threshold threshold-value	The default threshold for source MAC-based ARP attack detection is 50.
4. Set the aging timer for ARP attack entries.	arp source-mac aging-time time	By default, the lifetime is 300 seconds.
5. (Optional.) Exclude specific MAC addresses from this detection.	arp source-mac exclude-mac mac-address&<1-10>	By default, no MAC address is excluded.

NOTE:

When an ARP attack entry is aged out, ARP packets sourced from the MAC address in the entry can be processed correctly.

Displaying and maintaining source MAC-based ARP attack detection

Execute display commands in any view.

Task	Command
Display ARP attack entries detected by source MAC-based ARP attack detection.	display arp source-mac { slot slot-number \| interface interface-type interface-number }

Configuration example

Network requirements

As shown in Figure 124, the hosts access the Internet through a gateway (Device). 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 124 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 in the following steps:

1. Enable source MAC-based ARP attack detection and specify the handling method as filter.

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

<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

# Exclude MAC address 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. This feature allows the gateway to 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 valid-check enable	By default, ARP packet source MAC address consistency check is disabled.

Configuring ARP active acknowledgement

Configure this feature on gateways to prevent user spoofing.

ARP active acknowledgement prevents a gateway from generating incorrect ARP entries.

In strict mode, a gateway performs more strict validity checks before creating an ARP entry:

· Upon receiving an ARP request destined for the gateway, the gateway sends an ARP reply but does not create an ARP entry.

· Upon receiving an ARP reply, the gateway determines whether it has resolved the sender IP address:

? If yes, the gateway performs active acknowledgement. When the ARP reply is verified as valid, the gateway creates an ARP entry.

? If no, the gateway discards the packet.

To configure ARP active acknowledgement:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the ARP active acknowledgement feature.	arp active-ack [ strict ] enable	By default, this feature is disabled.

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. For more information about DHCP server and DHCP relay agent, see Layer 3—IP Services Configuration Guide.

With authorized ARP enabled, an interface is disabled from learning dynamic ARP entries. This feature prevents user spoofing and allows only authorized clients to access network resources.

Configuration procedure

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. Enable authorized ARP on the interface.	arp authorized enable	By default, authorized ARP is disabled.

Configuration example (on a DHCP server)

Network requirements

As shown in Figure 125, configure authorized ARP on VLAN-interface 10 of the AC (a DHCP server) to ensure user validity.

Figure 125 Network diagram

Configuration procedure

# Configure DHCP.

<AC> system-view

[AC] dhcp enable

[AC] dhcp server ip-pool 1

[AC-dhcp-pool-1] network 10.1.1.0 mask 255.255.255.0

[AC-dhcp-pool-1] quit

# Specify the IP address for VLAN-interface 10.

[AC] interface vlan-interface 10

[AC-Vlan-interface10] ip address 10.1.1.1 24

# Enable authorized ARP.

[AC-Vlan-interface10] arp authorized enable

[AC-Vlan-interface10] quit

Verifying the configuration

# Display authorized ARP entry information on the AC.

[AC] display arp

Type: S-Static D-Dynamic O-Openflow R-Rule I-Invalid

IP Address MAC Address VLAN Interface Aging Type

10.1.1.2 0012-3f86-e94c N/A GE1/0/1 20 D

The output shows that IP address 10.1.1.2 has been assigned 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. Thus user validity is ensured.

Configuration example (on a DHCP relay agent)

Network requirements

As shown in Figure 126, configure authorized ARP on VLAN-interface 20 of the AC (a DHCP relay agent) to ensure user validity.

Figure 126 Network diagram

Configuration procedure

1. Configure the switch:

# Specify the IP address for VLAN-interface 10.

<Switch> system-view

[Switch] interface vlan-interface 10

[Switch-Vlan-interface10] ip address 10.1.1.1 24

[Switch-Vlan-interface10] quit

# Configure DHCP.

[Switch] dhcp enable

[Switch] dhcp server ip-pool 1

[Switch-dhcp-pool-1] network 10.10.1.0 mask 255.255.255.0

[Switch-dhcp-pool-1] gateway-list 10.10.1.1

[Switch-dhcp-pool-1] quit

[Switch] ip route-static 10.10.1.0 24 10.1.1.2

2. Configure the AC:

# Enable DHCP.

<AC> system-view

[AC] dhcp enable

# Specify the IP addresses of VLAN-interface 10 and VLAN-interface 20.

[AC] interface vlan-interface 10

[AC-Vlan-interface10] ip address 10.1.1.2 24

[AC-Vlan-interface10] quit

[AC] interface vlan-interface 20

[AC-Vlan-interface20] ip address 10.10.1.1 24

# Enable DHCP relay agent on VLAN-interface 20.

[AC-Vlan-interface20] dhcp select relay

# Add the DHCP server 10.1.1.1 to DHCP server group 1.

[AC-Vlan-interface20] dhcp relay server-address 10.1.1.1

# Enable authorized ARP.

[AC-Vlan-interface20] arp authorized enable

[AC-Vlan-interface20] quit

# Enable recording of relay entries on the relay agent.

[AC] dhcp relay client-information record

Verifying the configuration

# Display authorized ARP information on the AC.

[AC] display arp

Type: S-Static D-Dynamic O-Openflow R-Rule I-Invalid

IP Address MAC Address VLAN Interface Aging Type

10.10.1.2 0012-3f86-e94c N/A GE1/0/2 20 D

The output shows that the DHCP server assigned the IP address 10.10.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. Thus the user validity is ensured.

Configuring ARP attack detection

ARP attack detection enables access devices to block ARP packets from unauthorized clients to prevent user spoofing and gateway spoofing attacks. ARP attack detection does not check ARP packets received from ARP trusted interfaces.

ARP attack detection provides the user validity check, ARP packet validity check, and ARP restricted forwarding features.

If both ARP packet validity check and user validity check are enabled, the former one applies first, and then the latter applies.

Configuring user validity check

User validity check compares the sender IP and sender MAC in the received ARP packet with the matching criteria in the following order:

1. User validity check rules.

? If a match is found, the device processes the ARP packet according to the rule.

? If no match is found or no user validity check rule is configured, proceeds to step 2.

2. 802.1X security entries.

? If a match is found, the device forwards the ARP packet.

? If no match is found, the device discards the ARP packet.

802.1X security entries record the IP-to-MAC mappings for 802.1X clients. After a client passes 802.1X authentication and uploads its IP address to an ARP attack 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."

Configuration guidelines

Make sure one or more of the following items is configured for user validity check:

· User validity check rules.

· 802.1X.

If none of the items is configured, all incoming ARP packets on ARP untrusted interfaces are discarded.

Configuration procedure

To configure user validity check:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. (Optional.) Configure a user validity check rule.	arp detection rule rule-id { deny \| permit } ip { ip-address [ mask ] \| any } mac { mac-address [ mask ] \| any } [ vlan vlan-id ]	By default, no user validity check rule is configured.
3. Enter VLAN view.	vlan vlan-id	N/A
4. Enable ARP attack detection.	arp detection enable	By default, ARP attack detection is disabled.
5. Return to system view.	quit	N/A
6. Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view.	interface interface-type interface-number	N/A
7. (Optional.) Configure the interface as a trusted interface excluded from ARP attack detection.	arp detection trust	By default, an interface is untrusted.

Configuring ARP packet validity check

Enable validity check for ARP packets received on untrusted interfaces and specify the following objects to be checked:

· src-mac—Checks 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-mac—Checks 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.

· ip—Checks the sender and target IP addresses of ARP replies, and the sender IP address of ARP requests. 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 attack detection.	arp detection enable	By default, ARP attack detection is disabled.
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 } *	By default, ARP packet validity check is disabled.
6. Enter Layer 2 Ethernet interface view or Layer 2 aggregate interface view.	interface interface-type interface-number	N/A
7. (Optional.) Configure the interface as a trusted interface excluded from ARP attack detection.	arp detection trust	By default, an interface is untrusted.

Configuring ARP restricted forwarding

NOTE:

ARP restricted forwarding does not apply to ARP packets with multiport MAC as their destination MAC addresses.

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.

Configure user validity check before you configure ARP restricted forwarding.

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	By default, ARP restricted forwarding is disabled.

Displaying and maintaining ARP attack detection

Execute display commands in any view.

Task	Command
Display the VLANs enabled with ARP attack detection.	display arp detection
Display the ARP attack detection statistics.	display arp detection statistics [ interface interface-type interface-number ]

User validity check configuration example

Network requirements

As shown in Figure 127, configure the AC to perform user validity check based on 802.1X security entries for the clients.

Figure 127 Network diagram

Configuration procedure

1. Add all interfaces on the AC to VLAN 10, and specify the IP address of VLAN-interface 10 on the switch. (Details not shown.)

2. Configure the DHCP server on the switch, and configure DHCP address pool 0.

<Switch> system-view

[Switch] dhcp enable

[Switch] dhcp server ip-pool 0

[Switch-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 attack detection. (Details not shown.)

4. Configure the AC:

# Configure the AC to perform EAP termination and use CHAP to communicate with the RADIUS server.

<AC> system-view

[AC] dot1x authentication-method chap

# Create an ISP domain named local and enter ISP domain view.

[AC] domain local

# Configure the ISP domain to use local authentication, local authorization, and local accounting for LAN clients.

[AC-isp-local] authentication lan-access local

[AC-isp-local] authorization lan-access local

[AC-isp-local] accounting lan-access local

[AC-isp-local] quit

# Create a service template named wlas_local_chap and enter its view.

[AC] wlan service-template wlas_local_chap

# Set the authentication mode to 802.1X.

[AC-wlan-st-wlas_local_chap] client-security authentication-mode dot1x

# Specify ISP domain local for the service template.

[AC-wlan-st-wlas_local_chap] dot1x domain local

# Set the SSID to wlas_local_chap.

[AC-wlan-st-wlas_local_chap] ssid wlas_local_chap

# Enable the service template.

[AC-wlan-st-wlas_local_chap] service-template enable

[AC-wlan-st-wlas_local_chap] quit

# # Create AP ap1, and specify the AP model and serial ID.

[AC] wlan ap ap1 model WA536-WW

[AC-wlan-ap-ap 1] serial-id 219801A1NQB117012935

[AC-wlan-ap-ap 1] quit

# Configure channel 149 as the working channel for radio 1 of the AP, and enable radio 1.

[AC] wlan ap ap1

[AC-wlan-ap-ap1] radio 1

[AC-wlan-ap-ap1-radio-1] channel 149

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

# Bind service template wlas_local_chap to radio 1.

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

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

[AC-wlan-ap-ap1] quit

# Add a network access user named test.

[AC] local-user test class network

[AC-luser-network-test] service-type lan-access

[AC-luser-network-test] password simple test

[AC-luser-network-test] quit

# Enable ARP attack detection for VLAN 10 to check user validity based on 802.1X entries.

[AC] vlan 10

[AC-vlan10] arp detection enable

# Configure the upstream interface as an ARP trusted interface. By default, an interface is an untrusted interface.

[AC-vlan10] interface gigabitethernet 1/0/3

[AC-GigabitEthernet1/0/3] arp detection trust

[AC-GigabitEthernet1/0/3] quit

After the configurations are completed, ARP packets received on interfaces GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 are checked against 802.1X entries.

Configuring ARP scanning and fixed ARP

ARP scanning is typically used together with the fixed ARP feature in small-scale networks.

ARP scanning automatically creates ARP entries for devices in an address range. The device performs ARP scanning in the following steps:

1. Sends ARP requests for each IP address in the address range.

2. Obtains their MAC addresses through received ARP replies.

3. Creates dynamic ARP entries.

Fixed ARP converts existing dynamic ARP entries (including those generated through ARP scanning) to static ARP entries. This feature prevents ARP entries from being modified by attackers. Static ARP entries can also be manually configured by the arp static command.

Configuration restrictions and guidelines

Follow these restrictions and guidelines when you configure ARP scanning and fixed ARP:

· IP addresses in existing ARP entries are not scanned.

· ARP scanning will take some time. To stop an ongoing scan, press Ctrl + C. Dynamic ARP entries are created based on ARP replies received before the scan is terminated.

· The arp fixup command is a one-time operation. You can use this command again to convert the dynamic ARP entries learned later to static.

· Due to the limit on the total number of static ARP entries, some dynamic ARP entries might fail the conversion.

· To delete a static ARP entry converted from a dynamic one, use the undo arp ip-address command.

Configuration procedure

To configure ARP scanning and fixed ARP:

Step	Command
1. Enter system view.	system-view
2. Enter Layer 3 Ethernet interface, Layer 3 Ethernet subinterface, or VLAN interface view.	interface interface-type interface-number
3. Enable ARP scanning.	arp scan [ start-ip-address to end-ip-address ]
4. Return to system view.	quit
5. Enable fixed ARP.	arp fixup

Configuring ARP gateway protection

Configure this feature on interfaces not connected with a gateway to prevent gateway spoofing attacks.

When such an interface 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.

Configuration guidelines

Follow these guidelines when you configure ARP gateway protection:

· You can enable ARP gateway protection for a maximum of eight gateways on an interface.

· Do not configure both the arp filter source and arp filter binding commands on an interface.

· If ARP gateway protection works with ARP attack detection, ARP gateway protection applies first.

Configuration procedure

To configure ARP gateway protection:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter Layer 2 Ethernet interface or Layer 2 aggregate interface view.	interface interface-type interface-number	N/A
3. Enable ARP gateway protection for the specified gateway.	arp filter source ip-address	By default, ARP gateway protection is disabled.

Configuration example

Network requirements

As shown in Figure 128, Client 2 launches gateway spoofing attacks to the AC. As a result, traffic that the AC intends to send to the switch is sent to Client 2.

Configure Switch B to block such attacks.

Figure 128 Network diagram

Configuration procedure

# Configure ARP gateway protection on the AC.

<AC> system-view

[AC] interface gigabitethernet 1/0/1

[AC-GigabitEthernet1/0/1] arp filter source 10.1.1.1

[AC-GigabitEthernet1/0/1] quit

[AC] interface gigabitethernet 1/0/2

[AC-GigabitEthernet1/0/2] arp filter source 10.1.1.1

Verifying the configuration

# Verify that GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 discard the incoming ARP packets whose sender IP address is the IP address of the gateway.

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.

Configuration guidelines

Follow these guidelines when you configure ARP filtering:

· You can configure a maximum of eight permitted entries on an interface.

· Do not configure both the arp filter source and arp filter binding commands on an interface.

· If ARP filtering works with ARP attack detection, ARP filtering applies first.

Configuration procedure

To configure ARP filtering:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter Layer 2 Ethernet interface or Layer 2 aggregate 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	By default, ARP filtering is disabled.

Configuration example

Network requirements

As shown in Figure 129, the IP and MAC addresses of Client 1 are 10.1.1.2 and 000f-e349-1233, respectively. The IP and MAC addresses of Client 2 are 10.1.1.3 and 000f-e349-1234, respectively.

Configure ARP filtering on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 of the AC to permit ARP packets from only Client 1 and Client 2.

Figure 129 Network diagram

Configuration procedure

# Configure ARP filtering on the AC.

<AC> system-view

[AC] interface gigabitethernet 1/0/1

[AC-GigabitEthernet1/0/1] arp filter binding 10.1.1.2 000f-e349-1233

[AC-GigabitEthernet1/0/1] quit

[AC] interface gigabitethernet 1/0/2

[AC-GigabitEthernet1/0/2] arp filter binding 10.1.1.3 000f-e349-1234

Verifying the configuration

# Verify that GigabitEthernet 1/0/1 permits ARP packets from Client 1 and discards other ARP packets.

# Verify that GigabitEthernet 1/0/2 permits ARP packets from Client 2 and discards other ARP packets.

Configuring ND attack defense

Overview

IPv6 Neighbor Discovery (ND) attack defense is able to identify forged ND messages to prevent ND attacks.

The IPv6 ND protocol does not provide any security mechanisms and is vulnerable to network attacks. An attacker can send the following forged ICMPv6 messages to perform ND attacks:

· Forged NS/NA/RS messages with an IPv6 address of a victim host. The gateway and other hosts update the ND entry for the victim with incorrect address information. As a result, all packets intended for the victim are sent to the attacking host.

· Forged RA messages with the IPv6 address of a victim gateway. As a result, all hosts attached to the victim gateway maintain incorrect IPv6 configuration parameters and ND entries.

For information about the IPv6 ND protocol, see Layer 3–IP Services Configuration Guide.

Configuring source MAC consistency check for ND messages

The source MAC consistency check feature is typically configured on gateways to prevent ND attacks.

This feature checks the source MAC address and the source link-layer address for consistency for each arriving ND message.

· If the source MAC address and the source link-layer address are not the same, the device drops the packet.

· If the addresses are the same, the device continues learning ND entries.

The ND logging feature logs source MAC inconsistency events, and it sends the log messages to the information center. The information center can then output log messages from different source modules to different destinations. For more information about the information center, see Network Management and Monitoring Configuration Guide.

To configure source MAC consistency check for ND messages:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable source MAC consistency check for ND messages.	ipv6 nd mac-check enable	By default, source MAC consistency check is disabled for ND messages.
3. (Optional.) Enable the ND logging feature.	ipv6 nd check log enable	By default, the ND logging feature is disabled. H3C recommends that you disable the ND logging feature to avoid excessive ND logs.

Configuring user isolation

Overview

The user isolation feature isolates packets for users that use the same SSID in the same VLAN or for users that are in the same VLAN. This feature improves user security, relieves the forwarding stress of the device, and reduces consumption of radio resources.

User isolation includes the following types:

· SSID-based user isolation—Isolates wireless users that use the same SSID in the same VLAN.

· VLAN-based user isolation—Isolates wired or wireless users in the same VLAN.

SSID-based user isolation

SSID-based user isolation is applicable to both the local forwarding mode and the centralized forwarding mode.

When SSID-based user isolation is enabled for a service, the device isolates all wireless users that access the network through the service in the same VLAN.

User isolation mechanism in centralized forwarding mode

As shown in Figure 130, the AC centrally forwards the client traffic. Client 1 to Client 3 access the WLAN through AP 1 to AP 3 by using the service named service. Client 1 and Client 2 are in VLAN 100, and Client 3 is in VLAN 200. Enable user isolation on the AC for the service.

· Client 1 sends broadcast or multicast packets in VLAN 100. When the AC receives the packets, it does not forward them to any APs in the WLAN. The AC forwards the packets only through the wired port to the switch.

· Client 1 sends unicast packets to Client 2 in VLAN 100. When the AC receives the packets, it discards them instead of forwarding them to AP 2.

Figure 130 Packet forwarding path

User isolation mechanism in local forwarding mode

This mechanism isolates wireless clients on an AP.

As shown in Figure 131, the APs perform local traffic forwarding for clients. Client 1 to Client 4 access the WLAN through AP 1 to AP 3 by using the service named service. Client 1 to Client 3 are in VLAN 100, and Client 4 is in VLAN 200. Enable SSID-based user isolation on the service for AP 1.

· Client 1 sends broadcast or multicast packets in VLAN 100.

? When AP 1 receives the packets, it does not forward them to Client 2 because user isolation is enabled. The AP forwards the packets only through the wired port to the wired devices in the same VLAN, including AP 2, AP 3, and the host.

? When AP 2 receives the packets, it forwards them to Client 3 because user isolation is disabled on AP 2.

? When AP 3 receives the packets, it does not forward them to Client 4 because Client 1 and Client 4 are in different VLANs.

· Client 1 sends unicast packets to Client 2 in VLAN 100. When AP 1 receives the packets, it discards them instead of forwarding them to Client 2.

Figure 131 Packet forwarding path

VLAN-based user isolation

VLAN-based user isolation is applicable to both local and centralized forwarding modes. Table 11 shows the mechanism to isolate traffic of wired users and wireless users.

Table 11 VLAN-based user isolation mechanism

Forwarding mode	Received unicast packets	Received broadcast or multicast packets
Centralized forwarding	The AC discards the packets.	The AC forwards the packets only through wired ports to the wired users in the VLAN, and it does not forward the packets to wireless users in the VLAN.
Local forwarding	The fit AP discards the packets.	The fit AP forwards the packets to wired and wireless users in the VLAN through wired ports. However, the AP does not forward the packets to the local wireless users in the VLAN.

User isolation mechanism in centralized forwarding mode

For packets received from wireless users

As shown in Figure 132, the AC centrally forwards the client traffic. Enable user isolation on the AC for VLAN 100.

· Client 1 sends unicast packets to Client 3 in VLAN 100. When the AC receives the packets, it discards them instead of forwarding them to AP 2.

Figure 132 Packet forwarding path

For packets received from wired users

As shown in Figure 133, the AC centrally forwards the client traffic. Enable user isolation on the AC for VLAN 100.

· The host sends broadcast or multicast packets in VLAN 100. The server and AC can receive the packets. When the AC receives the packets, it discards them instead of forwarding them to any APs in the WLAN.

· The host sends unicast packets to Client 3 in VLAN 100. When the AC receives the packets, it discards them instead of forwarding them to AP 2.

Figure 133 Packet forwarding path

User isolation mechanism in local forwarding mode

For packets received from wireless users

As shown in Figure 134, AP 1 performs local forwarding for clients. Enable user isolation on AP 1 for VLAN 100.

· Client 1 sends broadcast or multicast packets in VLAN 100.

? When AP 1 receives the packets, it forwards them to the server, AP 2, and the host in VLAN 100 through the wired port. However, AP 1 does not forward the packets to Client 2 because user isolation is enabled.

? When AP 2 receives the packets, it forwards them to Client 3 since user isolation is not enabled on AP 2.

· Client 1 sends unicast packets to Client 3 in VLAN 100. When AP 1 receives the packets, it discards them instead of forwarding them to AP 2.

Figure 134 Packet forwarding path

For packets received from wired users

As shown in Figure 135, AP 1 performs local forwarding for clients. Enable user isolation on AP 1 for VLAN 100.

· The host sends broadcast or multicast packets in VLAN 100. The server, AC, AP 1, and AP 2 can receive the packets.

? When AP 1 receives the packets, it discards them instead of forwarding them to Client 1 and Client 2.

? When AP 2 receives the packets, it forwards them to Client 3 since user isolation is not enabled on AP 2.

· The host sends unicast packets to Client 1 in VLAN 100. When AP 1 receives the packets, it discards them instead of forwarding them to Client 1.

Figure 135 Packet forwarding path

Enabling SSID-based user isolation

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter service template view.	wlan service-template service-template-name	N/A
3. Enable SSID-based user isolation.	user-isolation enable	By default, SSID-based user isolation is disabled. To display the status of SSID-based user isolation, use the display wlan service-template command. For information about this command, see WLAN Command Reference.

Configuring VLAN-based user isolation

Restrictions and guidelines

When you configure VLAN-based user isolation, follow these restrictions and guidelines:

· To enable users in a VLAN to access the external network, assign the VLAN gateway MAC address to the permitted MAC address list before you enable VLAN-based user isolation.

· VLAN-based user isolation applies to both the centralized forwarding mode and the local forwarding mode.

? In centralized forwarding mode, configure this feature directly on the AC.

? In local forwarding mode, you must use the map-configuration command to deploy a configuration file that contains user isolation configuration to the AP to enable this feature. For more information about configuration file deployment, see WLAN Configuration Guide.

Procedure

To configure VLAN-based user isolation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. (Optional.) Configure permitted MAC address list for a list of VLANs.	user-isolation vlan vlan-list permit-mac mac-list	By default, no permitted MAC addresses are configured for a VLAN. The device can forward unicast, multicast, and broadcast traffic sent by the users of permitted MAC addresses and can forward unicast traffic sent from other users to these users.
3. Enable user isolation for a list of VLANs.	user-isolation vlan vlan-list enable [ permit-unicast ]	By default, user isolation is disabled for a VLAN. Specify the permit-unicast keyword to allow unicast traffic of all users in the specified VLANs.
4. (Optional.) Permit broadcast and multicast traffic sent from wired users to wireless users.	user-isolation permit-broadcast	By default, the device does not forward broadcast or multicast traffic sent from wired users to wireless users in the VLANs where user isolation is enabled.

Displaying and maintaining user isolation

Execute display commands in any view and reset commands in user view.

Task	Command
Display user isolation statistics for a VLAN or for all VLANs.	display user-isolation statistics [ vlan vlan-id ]
Clear user isolation statistics for a VLAN or for all VLANs.	reset user-isolation statistics [ vlan vlan-id ]

User isolation configuration examples

SSID-based user isolation configuration example (centralized forwarding mode)

Network requirements

As shown in Figure 136, Client 1 and Client 2 use the same SSID to access the Internet. The AC centrally forwards the client traffic.

Configure user isolation on the AC to isolate the clients from each other while providing Internet access for the clients.

Figure 136 Network diagram

Configuration procedure

# Configure Client 1 and Client 2 to access the Internet through service template service. (Details not shown. For more information, see WLAN Configuration Guide.)

# Enable SSID-based user isolation for service template service.

<AC> system-view

[AC] wlan service-template service

[AC-wlan-st-service] user-isolation enable

[AC-wlan-st-service] quit

Verifying the configuration

# Verify that Client 1 and Client 2 can use service service to access the Internet but cannot access each other. (Details not shown.)

SSID-based user isolation configuration example (local forwarding mode)

Network requirements

As shown in Figure 137, Client 1 and Client 2 use the same SSID to access the Internet. The APs perform local traffic forwarding.

Configure user isolation for AP 1 to isolate the clients from each other while providing Internet access for the clients.

Figure 137 Network diagram

Configuration procedure

# Configure Client 1 and Client 2 to access the Internet through service template service1. Configure the APs to perform local traffic forwarding for the clients. (Details not shown. For more information, see WLAN Configuration Guide.)

# Enable SSID-based user isolation for service template service1.

<AC> system-view

[AC] wlan service-template service1

[AC-wlan-st-service1] user-isolation enable

[AC-wlan-st-service1] quit

Verifying the configuration

# Verify that Client 1 and Client 2 can use service service1 to access the Internet but cannot access each other. (Details not shown.)

VLAN-based user isolation configuration example (centralized forwarding mode)

Network requirements

As shown in Figure 138, the AC centrally forwards the client traffic and the router acts as the gateway of the devices in VLAN 2. The MAC address of the gateway is 000f-e212-7788.

Configure user isolation for VLAN 2 on the AC. Add the MAC address of the gateway to the permitted MAC address list to make sure Client 1, Client 2, the host, and the server can access the Internet.

Figure 138 Network diagram

Configuration procedure

# Configure Client 1 and Client 2 to access the Internet through WLAN. (Details not shown. For more information, see WLAN Configuration Guide.)

# Assign the MAC address of the gateway to the permitted MAC address list.

<AC> system-view

[AC] user-isolation vlan 2 permit-mac 000f-e212-7788

# Enable VLAN-based user isolation for VLAN 2.

[AC] user-isolation vlan 2 enable

Verifying the configuration

# Verify that Client 1, Client 2, the host, and the server in VLAN 2 can access the Internet. (Details not shown.)

VLAN-based user isolation configuration example (local forwarding mode)

Network requirements

As shown in Figure 139, AP 1 performs local traffic forwarding for the clients and the router acts as the gateway of the devices in VLAN 100. The MAC address of the gateway is 000f-e212-7788.

Configure user isolation for VLAN 100 on AP 1. Add the MAC address of the gateway to the permitted MAC address list to make sure Client 1 and Client 2 can access the Internet.

Figure 139 Network diagram

Configuration procedure

# Configure Client 1 and Client 2 to access the Internet through WLAN. (Details not shown. For more information, see WLAN Configuration Guide.)

# Create configuration file apcfg.txt and add user isolation command lines in the configuration file. You must place the command for adding the gateway MAC address to the permitted MAC address list before the command for enabling user isolation.

system-view

user-isolation vlan 100 permit-mac 000f-e212-7788

user-isolation vlan 100 enable

# Upload configuration file apcfg.txt to the AC. (Details not shown.)

# Issue configuration file apcfg.txt to AP 1.

<AC> system-view

[AC] wlan ap ap1 model WA536-WW

[AC-wlan-ap-ap1] map-configuration apcfg.txt

Verifying the configuration

# Verify that Client 1 and Client 2 in VLAN 100 can access the Internet. (Details not shown.)

Configuring ASPF

The term "firewall" in this document refers to access controllers and access controller modules.

Overview

Advanced Stateful Packet Filter (ASPF) is proposed to address the issues that a packet-filter firewall cannot solve. An ASPF provides the following main functions:

· Application layer protocol inspection—ASPF checks the application layer information of packets, such as the protocol type and port number, and inspects the application layer protocol status for each connection. ASPF maintains the status information of each connection, and based on the status information, determines whether to permit a packet to pass through the firewall into the internal network. In this way, ASPF defends the internal network against attacks.

· Transport layer protocol inspection (generic TCP and UDP inspection)—ASPF checks a TCP/UDP packet's source and destination addresses and port numbers to determine whether to permit the packet to pass through the firewall into the internal network.

· ICMP error message check—ASPF inspects the connection information carried in an ICMP error message. If the information does not match the connection, ASPF drops the packet.

· TCP SYN check—ASPF checks the first packet of a TCP connection to determine if it is a SYN packet. If it is not a SYN packet, ASPF drops the packet. When a device attached to the network starts up, it can receive a non-SYN packet of an existing TCP connection for the first time. If you do not want to interrupt the existing TCP connection, you can disable the TCP SYN check. The device allows the first non-SYN packet that is used to establish a TCP connection to pass. After the network topology becomes steady, you can enable TCP SYN check again.

At the border of a network, ASPF can work with a packet-filter firewall to provide the network with a more comprehensive security policy that better meets the actual needs. The packet-filter firewall permits or denies packets according to ACL rules. The ASPF records information about the permitted packets to ensure that their return packets can pass through the packet-filter firewall.

ASPF basic concepts

Single-channel protocol and multichannel protocol

· Single-channel protocol—A single-channel protocol establishes only one connection to exchange both control messages and data for a user. SMTP and HTTP are examples of single-channel protocols.

· Multichannel protocol—A multichannel protocol establishes more than one connection for a user and transfers control messages and user data through different connections. FTP is one example of multichannel protocols.

Internal interface and external interface

On an edge device configured with ASPF to protect hosts and servers on the internal network, the interfaces on the device are divided into internal interfaces and external interface:

· Internal interfaces—Interfaces connected to the internal network.

· External interfaces—Interfaces connected to the external network.

To protect the internal network, you can apply an ASPF in the outbound direction of the external interfaces or in the inbound direction of the internal interfaces of the device.

ASPF inspections

This section introduces the basic idea of ASPF inspection on application layer and transport layer protocols.

Application layer protocol inspection

As shown in Figure 140, ACLs on the edge device deny incoming packets to the internal network. The ASPF application layer protocol inspection allows return packets from the external network to the internal network.

Figure 140 Application layer protocol inspection

ASPF inspects all application layer sessions as follows:

· For a single-channel protocol, the inspection process is simple.

ASPF creates a session entry immediately after it detects the session's first packet sent to the external network, and ASPF removes the entry when the connection is terminated.

The session entry helps record outgoing packets and their return packets. It can maintain the session status and determine whether state transitions of the session are correct. All packets that match a session entry can pass through the packet-filter firewall.

· For a multichannel protocol, ASPF creates session entries, and one or more associated entries to associate the sessions initiated by the same application layer protocol. Associated entries are created during the protocol negotiation and are removed after the negotiation. ASPF uses the associated entries to match the first packets of the sessions. All packets of the sessions matching the associated entries can pass through the packet-filter firewall.

The following uses FTP to explain the process of multichannel application layer protocol inspection.

Figure 141 FTP inspection

As shown in Figure 141, FTP connections are established and removed as follows:

1. The FTP client initiates an FTP control connection from port 1333 to port 21 of the FTP server.

2. As a result of negotiation, the server initiates a data connection from port 20 to port 1600 of the client.

3. When data transmission times out or ends, the data connection is removed.

ASPF implements FTP inspection during the FTP connection lifetime as follows:

4. ASPF checks the IP packets the FTP client sends to the FTP server to identify TCP-based FTP packets. Based on the port number, ASPF identifies the control connection between the FTP client and server and creates a control connection session entry.

5. ASPF checks each FTP control connection packet, and examines their TCP status based on the control connection session entry. ASPF analyzes the FTP instructions in the control connection packet. If the packet contains a data channel setup instruction, ASPF creates an associated entry for the data connection.

6. For return FTP control connection packets, ASPF examines their TCP status based on the control connection session entry to make packet forwarding decisions.

7. When the FTP data passes through the device, ASPF is triggered to create a session entry for the data connection and remove the associated entry.

8. For returned FTP data packets, ASPF examines their TCP status based on the data connection session entry to make packet forwarding decisions.

9. When the data transmission ends, ASPF removes the data connection session entry. When the FTP connection is removed, ASPF removes the control connection session entry.

Transport layer protocol inspection

The transport layer protocol inspection refers to generic TCP/UDP inspection. It creates session entries to record the transport layer information of the packets to dynamically filter TCP and UDP packets. The transport layer information includes source and destination addresses and port numbers.

Generic TCP/UDP inspection requires that return packets must match the corresponding packets that are previously sent out of the external interface. The return packets must have the same source/destination addresses and source/destination port numbers as the outgoing packets (but reversed). Otherwise, the return packets are blocked. For multichannel application layer protocols like FTP, the deployment of TCP inspection without application layer inspection leads to failure of establishing a data connection.

Command and hardware compatibility

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

ASPF configuration task list

Tasks at a glance
(Required.) Configuring an ASPF policy
(Required.) Applying an ASPF policy to an interface

Configuring an ASPF policy

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an ASPF policy and enter its view.	aspf-policy aspf-policy-number	By default, no ASPF policies exist.
3. (Optional.) Configure ASPF inspection for application layer protocols.	detect { ftp \| h323 \| sccp \| sip \| gtp \| ils \| mgcp \| nbt \| pptp \| rsh \| rtsp \| sqlnet \| tftp \| xdmcp }	By default, ASPF inspection for application protocols is not configured. ASPF inspection for transport layer protocols is always enabled and is not configurable.
4. (Optional.) Enable ICMP error message check.	icmp-error drop	By default, ICMP error message check is disabled. ASPF does not drop faked ICMP error messages.
5. (Optional.) Enable TCP SYN check.	tcp syn-check	By default, TCP SYN check is disabled. ASPF does not drop the non-SYN packet when it is the first packet to establish a TCP connection.

Applying an ASPF policy to an interface

You can apply an ASPF policy to inspect incoming or outgoing traffic on an interface. ASPF compares the packets against session entries. If a packet does not match any session entries, ASPF creates a new session entry.

You can apply both ASPF and packet filter to implement packet filtering. For example, you can apply a packet filtering policy to the inbound direction of the external interface and apply an ASPF policy to the outbound direction of the external interface. The application denies unsolicited access from the external network to the internal network and allows return packets from external to the internal network.

Check that a connection initiation packet and the corresponding return packet pass through the same interface, because an ASPF stores and maintains the application layer protocol status based on interfaces.

To apply an ASPF policy 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. Apply an ASPF policy to the interface.	aspf apply policy aspf-policy-number { inbound \| outbound }	By default, no ASPF policy is applied to the interface.

Displaying and maintaining ASPF

Execute display commands in any view and reset commands in user view.

Task	Command
Display the configuration of all ASPF policies and their applications.	display aspf all
Display ASPF policy applications on interfaces.	display aspf interface
Display the configuration of an ASPF policy.	display aspf policy { aspf-policy-number \| default }
Display ASPF sessions.	display aspf session [ ipv4 \| ipv6 ] [ slot slot-number ] [ verbose ]
Clear ASPF session statistics.	reset aspf session [ ipv4 \| ipv6 ] [ slot slot-number ]

ASPF configuration examples

ASPF FTP application inspection configuration example

Network requirements

Configure an ASPF policy on the AC to inspect the FTP traffic flows passing through the AC. Only return packets for FTP connections initiated by users on the internal network are permitted to pass through the AC and get into the internal network. All other types of packets from the external network to the internal network are blocked.

Figure 142 Network diagram

Configuration procedure

# Configure ACL 3111 to deny all IP packets.

<AC> system-view

[AC] acl advanced 3111

[AC-acl-ipv4-adv-3111] rule deny ip

[AC-acl-ipv4-adv-3111] quit

# Create ASPF policy 1 for FTP inspection.

[AC] aspf-policy 1

[AC-aspf-policy-1] detect ftp

[AC-aspf-policy-1] quit

# Apply ACL 3111 to deny all incoming IP packets on VLAN-interface 100.

[AC] interface vlan-interface 100

[AC-Vlan-interface100] packet-filter 3111 inbound

# Apply ASPF policy 1 to the outgoing traffic on VLAN-interface 100.

[AC-Vlan-interface100] aspf apply policy 1 outbound

Verifying the configuration

# Verify that an ASPF session has been established for the FTP connection between the host and the FTP server.

<AC> display aspf session ipv4

Initiator:

Source IP/port: 192.168.1.2/1877

Destination IP/port: 2.2.2.11/21

VPN instance/VLAN ID/Inline ID: -/-/-

Protocol: TCP(6)

Inbound interface: Vlan-interface 100

Total sessions found: 1

# Verify that only the return packets of FTP connections can enter the internal network. (Details not shown.)

ASPF TCP application inspection configuration example

Network requirements

Local users on the internal network need to access the external network. To protect the internal network against ICMP and SYN packet attacks from the external network, configure an ASPF policy on the AC. The AC can then drop faked ICMP error messages and non-SYN packets that are the first packets over TCP connections.

Figure 143 Network diagram

Configuration procedure

# Configure ACL 3111 to deny all IP packets.

<AC> system-view

[AC] acl advanced 3111

[AC-acl-ipv4-adv-3111] rule deny ip

[AC-acl-ipv4-adv-3111] quit

# Create ASPF policy 1.

[AC] aspf-policy 1

# Enable ICMP error message check.

[AC-aspf-policy-1] icmp-error drop

# Enable TCP SYN check.

[AC-aspf-policy-1] tcp syn-check

[AC-aspf-policy-1] quit

# Enable ASPF policy 1 to inspect FTP packets.

[AC-aspf-policy-1] detect ftp

# Apply ACL 3111 to deny all incoming IP packets on VLAN-interface 100.

[AC] interface Vlan-interface 100

[AC-Vlan-interface100] packet-filter 3111 inbound

# Apply ASPF policy 1 to outgoing traffic on interface VLAN-interface 100.

[AC-Vlan-interface100] aspf apply policy 1 outbound

Verifying the configuration

# Display the configuration of ASPF policy 1.

<AC> display aspf policy 1

ASPF policy configuration:

Policy number: 1

ICMP error message check: Enabled

TCP SYN packet check: Enabled

Inspected protocol

FTP

The AC can recognize faked ICMP error messages from external networks and drop the non-SYN packets that are the first packets to establish TCP connections.

Configuring protocol packet rate limit

The WX1800H series access controllers do not support the slot keyword or the slot-number argument.

Overview

The protocol packet rate limit feature rate limits packets sent to the CPU, effectively preventing flood and DoS attacks.

The device supports the following protocol packet rate limit methods:

· Protocol-based protocol packet rate limit—Limits the maximum transmission rate of protocol packets of a specific protocol. Excessive protocol packets are dropped.

· Flow-based protocol packet rate limit—Identifies flows of a protocol by source IP or MAC address, and limits the maximum transmission rate per flow. Excessive protocol packets are dropped. This method collects traffic statistics by flow and protocol for traffic anomaly and user behavior monitoring.

Configuration restrictions and guidelines

You can configure both protocol-based and flow-based protocol packet rate limit for the same protocol. The device first performs flow-based protocol packet rate limit and then performs protocol-based packet rate limit.

Configuring protocol packet rate limit

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable packet rate limit.	anti-attack enable [ slot slot-number ]	By default, packet rate limit is disabled.
3. Enable packet rate limit for a specific protocol or all protocols.	anti-attack protocol { all \| protocol } enable [ slot slot-number ]	By default, packet rate limit is disabled for all protocols.
4. (Optional.) Set the maximum transmission rate for a protocol.	anti-attack protocol protocol threshold rate-limit [ slot slot-number ]	To display the default setting for a protocol, execute the undo anti-attack protocol threshold and display anti-attack protocol commands in turn.
5. (Optional.) Set the packet process priority for a protocol	anti-attack protocol protocol priority priority [ slot slot-number ]	To display the default setting for a protocol, execute the undo anti-attack protocol priority and display anti-attack protocol commands in turn.
6. Enable flow-based packet rate limit for a protocol and set the maximum transmission rate per flow.	anti-attack protocol protocol flow-threshold flow-rate-limit [ slot slot-number ]	By default, flow-based packet rate limit is disabled for all protocols. This step is required only for flow-based packet rate limit.

Displaying and maintaining protocol packet rate limit

Use the display commands in any view.

Task	Command
Display protocol packet rate limit information.	display anti-attack protocol [ protocol ] [ slot slot-number ]

Protocol packet rate limit configuration examples

Protocol-based protocol packet rate limit configuration example

Network requirements

Configure protocol packet rate limit for ARP on the AC. Set the maximum transmission rate to 1000 packets per second.

Figure 144 Network diagram

Configuration procedure

# Enable packet rate limit.

<Sysname> system-view

[Sysname] anti-attack enable

# Enable packet rate limit for ARP.

[Sysname] anti-attack protocol arp enable

# Set the maximum transmission rate to 1000 packets per second for ARP.

[Sysname] anti-attack protocol arp threshold 1000

Verifying the configuration

# Display packet rate limit information about ARP after Client 1 and Client 2 are connected.

<Sysname> display anti-attack protocol arp

Anti-attack statistics

Protocol anti-attack Priority Limit(pps) Rate(pps) Passed Dropped

arp enable 1 1000 0 17907 0

Flow-based protocol packet rate limit configuration example

Network requirements

Configure flow-based protocol packet rate limit for ARP on the AC. Set the maximum transmission rate per flow to 50 packets per second.

Figure 145 Network diagram

Configuration procedure

# Enable packet rate limit.

<Sysname> system-view

[Sysname] anti-attack enable

# Enable packet rate limit for ARP.

[Sysname] anti-attack protocol arp enable

# Enable flow-based packet rate limit for ARP and set the maximum transmission rate per flow to 50 packets per second.

[Sysname] anti-attack protocol arp flow-threshold 50

Verifying the configuration

# Display packet rate limit information about ARP after Client 1 and Client 2 are connected.

<Sysname> display anti-attack protocol arp

Anti-attack statistics

Protocol anti-attack Priority Limit(pps) Rate(pps) Passed Dropped

arp enable 1 1024 0 17907 0

FlowSource FlowLimit(pps) FlowRate(pps) Passed Dropped

00e0-fc12-7723 50 0 2 0

Index

Numerics

3DES

IPsec encryption algorithm, 245

802.1X, 77, See also under 802

AAA RADIUS server 802.1X user, 67

ACL assignment, 85

architecture, 77

authentication, 81

authentication (access device initiated), 80

authentication (client initiated), 80

authentication initiation, 80

authentication request attempts max, 87

authentication timeout timers, 87

configuration, 85

controlled/uncontrolled port, 77

display, 89

EAD assistant configuration, 88

EAD assistant feature, 85

EAP over RADIUS, 79

EAP packet format, 78

EAP relay authentication, 82

EAP relay enable, 86

EAP relay termination, 83

EAP relay/termination authentication, 81

EAP termination enable, 86

EAP-Message attribute, 79

EAPOL packet format, 79

feature cooperation, 85

maintain, 89

overview, 77

packet format, 78

port authorization status, 77

RADIUS Message-Authentication attribute, 80

related protocols, 78

supported domain name delimiters, 88

troubleshooting, 89

troubleshooting EAD assistant Web browser users, 89

user profile assignment, 85

user profile configuration, 183, 184

VLAN manipulation, 85

802.1X client

anonymous identifier configuration, 93

configuration, 91, 91, 94

EAP authentication method, 92

enable, 91

password configuration, 92

username configuration, 92

AAA

BYOD endpoint identification rules, 53

BYOD endpoint type-specific authorization attributes, 54

concurrent login user max, 53

configuration, 1, 17, 57

device implementation, 12

display, 56

displaying local users/user groups, 24

HWTACACS accounting server, 36

HWTACACS authentication server, 35

HWTACACS authorization server, 36

HWTACACS display, 40

HWTACACS implementation, 7

HWTACACS maintain, 40

HWTACACS outgoing packet source IP address, 38

HWTACACS scheme, 35

HWTACACS scheme creation, 35

HWTACACS server SSH user, 57

HWTACACS shared keys, 37

HWTACACS timer set, 39

HWTACACS traffic statistics units, 37

HWTACACS username format, 37

HWTACACS/RADIUS differences, 7

IPsec IKE IPv4 address pool, 276

IPsec IKEv2 address pool, 290

ISP domain accounting method, 50

ISP domain attribute configuration, 46

ISP domain authentication method, 48

ISP domain authorization method, 49

ISP domain creation, 45

ISP domain method, 44

ITA policy configuration, 55

LDAP administrator attribute, 42

LDAP attribute map, 43

LDAP attribute map for authorization, 44

LDAP authentication server, 43

LDAP authorization server, 44

LDAP display, 44

LDAP implementation, 9

LDAP scheme, 40

LDAP scheme creation, 43

LDAP server creation, 41

LDAP server IP address, 41

LDAP server SSH user authentication, 63

LDAP user attribute, 42

LDAP versions, 41

local BYOD authorization, 53

local BYOD authorization display, 55

local guest attributes, 22

local guest configuration, 72

local guest management, 23, 72

local user attribute, 19

local user configuration, 18

methods, 12

NAS-ID profile configuration, 56

protocols and standards, 14

RADIUS accounting server parameters, 27

RADIUS accounting-on configuration, 32

RADIUS attributes, 14

RADIUS authentication server, 26

RADIUS DAE server (DAS), 52

RADIUS display, 34

RADIUS implementation, 2

RADIUS maintain, 34

RADIUS packet DSCP priority, 53

RADIUS request transmission attempts max, 28

RADIUS scheme, 25

RADIUS scheme creation, 26

RADIUS server 802.1X user, 67

RADIUS server SSH user authentication+authorization, 60

RADIUS server status, 29

RADIUS session-control, 51

RADIUS shared keys, 28

RADIUS SNMP notification, 34

RADIUS timer set, 31

RADIUS traffic statistics units, 28

RADIUS username format, 28

scheme configuration, 18

SSH user local authentication+HWTACACS authorization+RADIUS accounting, 58

troubleshoot HWTACACS, 75

troubleshoot LDAP, 76

troubleshoot LDAP authentication failure, 76

troubleshoot RADIUS, 74

troubleshoot RADIUS accounting error, 75

troubleshoot RADIUS authentication failure, 74

troubleshoot RADIUS packet delivery failure, 75

user group attribute, 21

user management by ISP domains, 12

user management by user access types, 12

portal authentication configuration on VLAN interface, 147

portal authentication extended configuration, 159

portal authentication server detection configuration, 162

access control

flow-base packet rate limit, 407

local MAC-based quick portal authentication configuration, 178

portal authentication, 108

portal authentication configuration, 101, 147

portal authentication configuration on service template, 152

portal authentication configuration on VLAN interface, 147

portal authentication extended configuration, 159

portal authentication server detection configuration, 162

protocol packet rate limit, 405, 405, 406

protocol-base packet rate limit, 406

remote MAC-based quick portal authentication configuration, 171

security portal authentication local portal Web server, 168

access control policy

PKI certificate-based access control policy, 231

accessing

portal authentication device access, 102

account idle time (password control), 191

accounting

AAA configuration, 1, 17, 57

AAA ISP domain accounting method, 50

AAA ITA policy configuration, 55

AAA RADIUS accounting server parameters, 27

AAA RADIUS accounting-on, 32

AAA SSH user local authentication+HWTACACS authorization+RADIUS accounting, 58

session management statistics collection, 345

ACK flood, 361

ACL

802.1X ACL assignment, 85

attack D&P detection exemption, 364

IPsec ACL, 249

IPsec ACL de-encapsulated packet check, 259

IPsec ACL rule keywords, 249

IPsec ACL-based tunnel establishment, 247

IPsec implementation (ACL-based), 248

IPsec mirror image ACLs, 250

IPsec non-mirror image ACLs, 250

SSH management parameters, 300

active

ARP active acknowledgement, 375

portal authentication type, 101

address pool

IPsec IKE IPv4 address pool, 276

IPsec IKEv2 address pool, 290

portal user preauthentication IP address pool, 118

Address Resolution Protocol. Use ARP

Advanced Stateful Packet Filter. See ASPF

AES

IPsec encryption algorithm, 245

aging

session management aging time (protocol state), 344

IPsec security protocol 51, 243

alert protocol (SSL), 336

algorithm

IPsec authentication, 245

IPsec encryption (3DES), 245

IPsec encryption (AES), 245

IPsec encryption (DES), 245

IPsec IKE DH algorithm, 268

SSH negotiation, 294

allowing

only portal clients with DHCP-assigned IP addresses to pass portal authentication, 120

anti-replay

IPsec anti-replay redundancy, 260

IPsec configuration, 259

any authentication (SSH), 294

application

IPsec application-based tunnel establishment, 247

applying

AAA ITA policy, 55

ASPF policy (interface), 401

attack D&P policy application (device), 365

attack D&P policy application (interface), 365

connection limit policy, 351

IPsec policy to interface, 258

portal authentication interface NAS ID profile, 129

architecture

802.1X, 77

PKI, 209

ARP

attack protection. See ARP attack protection

scanning configuration restrictions, 383

ARP attack protection

active acknowledgement, 375

ARP attack detection display, 380

ARP attack detection maintain, 380

authorized ARP configuration, 375

authorized ARP configuration (DHCP relay agent), 376

authorized ARP configuration (DHCP server), 376

command and hardware compatibility, 372

configuration, 372

detection configuration, 378

filtering configuration, 385, 385

fixed ARP configuration, 382

gateway protection, 383, 384

packet source MAC consistency check, 374

packet validity check configuration, 379

restricted forwarding, 379

scanning configuration, 382

source MAC-based attack detection, 372, 373

source MAC-based detection display, 373

user validity check, 378

user validity check configuration, 380

ARP entry

portal authentication enabling ARP entry conversion for portal clients, 134

ASPF

application inspection (FTP), 402

application inspection (TCP), 403

application layer protocol inspection, 399

basic concepts, 398

configuration, 398, 401, 402

display, 402

inspection, 399

maintain, 402

policy application (interface), 401

policy configuration, 401

session management, 343

session management configuration, 344

transport layer protocol inspection, 400

assigning

802.1X ACL assignment, 85

802.1X user profile assignment, 85

associating

IPsec SA, 245

attack

ARP attack protection configuration, 372

detection and prevention. See attack D&P

attack D&P

command and hardware compatibilityattack, 357

configuration, 354, 358

defense policy configuration, 358

defense policy configuration (ACK flood), 361

defense policy configuration (DNS flood), 364

defense policy configuration (FIN flood), 362

defense policy configuration (flood), 360

defense policy configuration (HTTP flood), 364

defense policy configuration (ICMP flood), 362

defense policy configuration (ICMPv6 flood), 363

defense policy configuration (RST flood), 362

defense policy configuration (scanning), 360

defense policy configuration (single-packet), 358

defense policy configuration (SYN flood), 360

defense policy configuration (SYN-ACK flood), 361

defense policy configuration (UDP flood), 363

defense policy creation, 358

detection exemption configuration, 364

device-preventable attacks, 354

display, 367

log aggregation disable, 366

maintain, 367

policy application (device), 365

policy application (interface), 365

TCP fragment attack prevention configuration, 366

attack detection and prevention. See attack D&P

attack prevention

ASPF application inspection (FTP), 402

ASPF application inspection (TCP), 403

ASPF configuration, 398, 401, 402

attribute

802.1X RADIUS EAP-Message, 79

802.1X RADIUS Message-Authentication, 80

AAA HWTACACS scheme, 35

AAA ISP domain attribute, 46

AAA LDAP administrator attribute, 42

AAA LDAP attribute map, 43

AAA LDAP attribute map for authorization, 44

AAA LDAP scheme, 40

AAA LDAP user attribute, 42

AAA local guest attributes, 22

AAA local user, 18

AAA local user attribute, 19

AAA RADIUS, 14

AAA RADIUS attribute 31 MAC address format, 33

AAA RADIUS common standard attributes, 14

AAA RADIUS extended attributes, 6

AAA RADIUS H3C proprietary attributes, 15

AAA RADIUS Login-Service attribute check method, 33

AAA RADIUS Remanent_Volume attribute data measurement unit, 33

AAA RADIUS scheme, 25

AAA scheme, 18

AAA user group attribute, 21

portal authentication NAS-Port-Id attribute format, 128

RADIUS NAS-Port-Type, 137

authenticating

802.1X access device initiated authentication, 80

802.1X authentication, 81

802.1X authentication request attempts max, 87

802.1X client-initiated, 80

802.1X EAP over RADIUS, 79

802.1X EAP relay authentication, 82

802.1X EAP relay enable, 86

802.1X EAP relay/termination, 81

802.1X EAP termination, 83

802.1X EAP termination enable, 86

802.1X initiation, 80

802.1X overview, 77

802.1X RADIUS Message-Authentication attribute, 80

802.1X timeout timers, 87

802.1X VLAN manipulation, 85

AAA configuration, 1, 17, 57

AAA ISP domain authentication method, 48

AAA LDAP authentication, 9

AAA LDAP process, 10

AAA LDAP server SSH user authentication, 63

AAA RADIUS server SSH user authentication+authorization, 60

AAA RADIUS user authentication methods, 2

AAA SSH user local authentication+HWTACACS authorization+RADIUS accounting, 58

IPsec, 245

IPsec authentication algorithms, 245

IPsec Authentication Header. Use AH

IPsec configuration, 243

IPsec Encapsulating Security Payload. Use ESP

IPsec IKE DSA signature authentication, 267

IPsec IKE pre-shared key authentication, 267

IPsec IKE RSA signature authentication, 267

IPsec RRI configuration, 263

MAC authentication, 97, 98

MAC authentication VLAN assignment, 98

password control configuration, 189, 191, 196

periodic MAC reauthentication, 98

portal authentication client, 102

portal authentication server, 102

portal preauthentication domain, 118

SSH configuration, 293

SSH methods, 294

SSH Secure Telnet client password authentication configuration, 319

SSH Secure Telnet client publickey authentication, 322

SSH Secure Telnet server password authentication, 311

SSH Secure Telnet server publickey authentication, 313

SSH server configuration, 295

SSH SFTP client publickey authentication, 326

SSH SFTP server password authentication, 324

SSL services, 336

user profile, 183

user profile configuration, 183, 184

authentication

802.1X client EAP authentication method, 92

Authentication, Authorization, and Accounting. Use AAA

authorized ARP

configuration, 375

configuration (DHCP relay agent), 376

configuration (DHCP server), 376

authorizing

802.1X port authorization status, 77

AAA BYOD endpoint identification rules, 53

AAA BYOD endpoint type-specific authorization attributes, 54

AAA configuration, 1, 17, 57

AAA ISP domain authorization method, 49

AAA LDAP authorization, 9

AAA LDAP process, 11

AAA RADIUS server SSH user authentication+authorization, 60

AAA RADIUS session-control, 51

AAA SSH user local authentication+HWTACACS authorization+RADIUS accounting, 58

IPsec IKE IPv4 address pool, 276

IPsec IKEv2 address pool, 290

portal authorization strict-checking mode, 119

auto

PKI certificate request (automatic), 214

BAS-IP

portal authentication BAS-IP, 126

binding

IPsec source interface to policy, 260

BYOD

AAA BYOD endpoint identification rules, 53

AAA BYOD endpoint type-specific authorization attributes, 54

AAA local authorization, 53

security portal authentication, 106

PKI architecture, 209

PKI CA policy, 209

PKI certificate, 208

PKI certificate export, 219

PKI certificate obtain, 216

PKI certificate removal, 219

PKI certificate request, 213

PKI certificate request (automatic), 214

PKI certificate request (manual), 215

PKI certificate request abort, 215

PKI certificate verification, 217

PKI CRL, 208

PKI domain configuration, 211

PKI entity configuration, 210

PKI OpenCA server certificate request, 228

PKI RSA Keon CA server certificate request, 221

PKI storage path, 218

PKI Windows 2003 CA server certificate request, 224

troubleshooting PKI CA certificate import failure, 240

troubleshooting PKI CA certificate obtain failure, 238

CAR

AAA RADIUS class attribute as CAR parameter, 32

centralized forwarding

portal authentication configuration, 107

certificate

authority. Use CA

PKI certificate verification (CRL checking), 217

PKI certificate verification (w/o CRL checking), 218

PKI certificate-based access control policy, 231

revocation list. Use CRL

change cipher spec protocol (SSL), 336

changing

AAA RADIUS packet DSCP priority, 53

checking

IPsec ACL de-encapsulated packet check, 259

PKI certificate verification (CRL checking), 217

PKI certificate verification (w/o CRL checking), 218

portal authorization strict-checking mode, 119

class

AAA RADIUS class attribute as CAR parameter, 32

classifying

IPsec QoS pre-classify enable, 261

clearing

IPsec packet DF bit clear, 262

client

802.1X authentication, 81

802.1X authentication (access device initiated), 80

802.1X authentication (client-initiated), 80

802.1X authentication client timeout timer, 87

802.1X authentication initiation, 80

802.1X client anonymous identifier configuration, 93

802.1X client configuration, 91, 91, 94

802.1X client username configuration, 92

802.1X configuration, 85

portal authentication, 102

portal authentication system components, 101

SSL client policy configuration, 338

command

AAA command accounting method, 12

AAA command authorization method, 12

SSH command and hardware compatibility, 295

user profile command and hardware compatibility, 183

command and hardware compatibility

ARP attack protection, 372

attack D&P configuration, 357

portal, 107

communication

peer public key entry, 203

comparing

802.1X EAP relay/termination authentication, 81

compatibility

SSH command and hardware compatibility, 295

user profile command and hardware compatibility, 183

complexity checking (password control), 189

composition checking (password control), 189

configuring

802.1X, 85

802.1X client, 91, 91, 94

802.1X client anonymous identifier, 93

802.1X client password, 92

802.1X client username, 92

802.1X EAD assistant, 88

AAA, 1, 17, 57

AAA BYOD endpoint identification rules, 53

AAA BYOD endpoint type-specific authorization attributes, 54

AAA HWTACACS schemes, 35

AAA HWTACACS server SSH user, 57

AAA ISP domain accounting method, 50

AAA ISP domain attribute, 46

AAA ISP domain authentication method, 48

AAA ISP domain authorization method, 49

AAA ISP domain method, 44

AAA ITA policy, 55

AAA LDAP administrator attributes, 42

AAA LDAP attribute map, 43

AAA LDAP scheme, 40

AAA LDAP server IP address, 41

AAA LDAP server SSH user authentication, 63

AAA LDAP user attributes, 42

AAA local BYOD authorization, 53

AAA local guest, 72

AAA local guest attributes, 22

AAA local user, 18

AAA local user attributes, 19

AAA NAS-ID profile, 56

AAA RADIUS accounting-on, 32

AAA RADIUS attribute 31 MAC address format, 33

AAA RADIUS DAE server (DAS), 52

AAA RADIUS Login-Service attribute check method, 33

AAA RADIUS scheme, 25

AAA RADIUS server 802.1X user, 67

AAA RADIUS server SSH user authentication+authorization, 60

AAA RADIUS server status detection test profile, 25

AAA RADIUS session-control, 51

AAA scheme, 18

AAA SSH user local authentication+HWTACACS authorization+RADIUS accounting, 58

AAA user group attributes, 21

ARP active acknowledgement, 375

ARP attack detection, 378

ARP attack detection (source MAC-based), 372, 373

ARP attack detection packet validity check, 379

ARP attack detection restricted forwarding, 379

ARP attack detection user validity check, 378, 380

ARP attack protection, 372

ARP filtering, 385, 385

ARP gateway protection, 383, 384

ARP packet source MAC consistency check, 374

ARP scanning, 382

ASPF, 398, 401, 402

ASPF application inspection (FTP), 402

ASPF application inspection (TCP), 403

ASPF policy, 401

attack D&P, 354, 358

attack D&P defense policy, 358

attack D&P defense policy (ACK flood), 361

attack D&P defense policy (DNS flood), 364

attack D&P defense policy (FIN flood), 362

attack D&P defense policy (flood), 360

attack D&P defense policy (HTTP flood), 364

attack D&P defense policy (ICMP flood), 362

attack D&P defense policy (ICMPv6 flood), 363

attack D&P defense policy (RST flood), 362

attack D&P defense policy (scanning), 360

attack D&P defense policy (single-packet), 358

attack D&P defense policy (SYN flood), 360

attack D&P defense policy (SYN-ACK flood), 361

attack D&P defense policy (UDP flood), 363

attack D&P detection exemption, 364

attack D&P policy application (device), 365

attack D&P policy application (interface), 365

attack D&P TCP fragment attack prevention, 366

authorized ARP, 375

authorized ARP (DHCP relay agent), 376

authorized ARP (DHCP server), 376

connection limit, 349, 352

connection limit policy, 350

email authentication, 142

fixed ARP, 382

flow-base packet rate limit, 407

IP source guard (IPSG), 369, 369, 370

IPsec, 243

IPsec ACL, 249

IPsec ACL anti-replay, 259

IPsec anti-replay redundancy, 260

IPsec fragmentation, 264

IPsec IKE, 266, 269

IPsec IKE DPD, 274

IPsec IKE global identity information, 273

IPsec IKE IPv4 address pool, 276

IPsec IKE keepalive, 274

IPsec IKE keychain, 272

IPsec IKE NAT keepalive, 274

IPsec IKE profile, 269

IPsec IKE proposal, 271

IPsec IKE SNMP notification, 276

IPsec IKEv2, 282, 284

IPsec IKEv2 address pool, 290

IPsec IKEv2 DPD, 289

IPsec IKEv2 global parameters, 289

IPsec IKEv2 keychain, 288

IPsec IKEv2 NAT keepalive, 290

IPsec IKEv2 policy, 287

IPsec IKEv2 profile, 284

IPsec IKEv2 proposal, 288

IPsec packet DF bit, 262

IPsec policy (IKE-based), 254

IPsec policy (IKE-based/direct), 255

IPsec policy (IKE-based/template), 256

IPsec policy (manual), 253

IPsec RRI, 263

IPsec SNMP notification, 264

IPsec transform set, 251

local MAC binding server, 136

local MAC-based quick portal authentication, 178

MAC authentication, 97, 98

MAC authentication server timeout timer, 99

MAC authentication user account format, 99

MAC-based quick portal authentication, 135

NAS-Port-Type, 137

ND attack defense, 387

NETCONF-over-SSH, 331

NETCONF-over-SSH client user line, 298

packet processing (unknown source IPv4 address), 370

password control, 189, 191, 196

PKI, 208, 210, 221

PKI certificate import/export, 232

PKI certificate request (automatic), 214

PKI certificate request (manual), 215

PKI certificate request abort, 215

PKI certificate-based access control policy, 220, 231

PKI domain, 211

PKI entity, 210

PKI OpenCA server certificate request, 228

PKI RSA Keon CA server certificate request, 221

PKI Windows 2003 CA server certificate request, 224

portal authentication, 101, 108, 147

portal authentication configuration on VLAN interface, 147

portal authentication destination subnet, 115

portal authentication detection features, 121

portal authentication extended configuration, 159

portal authentication fail-permit, 125

portal authentication HTTPS redirect, 134

portal authentication monitoring feature, 143

portal authentication on service template, 152

portal authentication portal-free rule, 114

portal authentication server, 109

portal authentication server BAS-IP, 126

portal authentication server detection, 122, 162

portal authentication user online detection, 121

portal authentication user synchronization, 124

portal authentication Web redirect, 128

portal authentication Web server, 110

portal authentication Web server detection, 123

portal safe-redirect, 138

portal support for third-party authentication, 140

portal temporary pass, 143

portal third-party authentication server, 141

protocol packet rate limit, 405, 405, 406

protocol-base packet rate limit, 406

public peer key, 202

QQ authentication server, 141

remote MAC binding server, 135

remote MAC-based quick portal authentication, 171

Secure Telnet client user line, 298

security local portal Web server feature, 130

security portal authentication local portal Web server, 132, 168

security portal wireless client validity check, 133

session management, 343, 344

session management logging, 346

source MAC consistency check, 387

SSH, 293

SSH client host public key, 298

SSH device as Secure Telnet client, 302

SSH device as server, 295

SSH device as SFTP client, 304

SSH management parameters, 300

SSH SCP, 330

SSH SCP client device, 307

SSH Secure Telnet, 311

SSH Secure Telnet client password authentication, 319

SSH Secure Telnet client publickey authentication, 322

SSH Secure Telnet server password authentication, 311

SSH Secure Telnet server publickey authentication, 313

SSH SFTP, 324

SSH SFTP client publickey authentication, 326

SSH SFTP server password authentication, 324

SSH user, 299

SSH2 algorithms (encryption ), 310

SSH2 algorithms (key exchange), 309

SSH2 algorithms (MAC), 310

SSH2 algorithms (public key), 309

SSID-based user isolation, 388

SSID-based user isolation (centralized forwarding mode), 394

SSID-based user isolation (local forwarding mode), 395

SSL, 336, 337

SSL client policy, 338

SSL server policy, 337, 340

user isolation, 388, 394

user profile, 183, 183, 184

VLAN-based user isolation, 389, 393

VLAN-based user isolation (centralized forwarding mode), 396

VLAN-based user isolation (local forwarding mode), 397

connecting

connection limit. See connection limit

connection limit

configuration, 349, 352

display, 351

maintain, 351

policy application, 351

policy configuration, 350

policy creation, 349

troubleshoot overlapping ACL segments, 353

connection limits

troubleshoot, 353

consistency check (ARP attack protection), 374

controlling

802.1X controlled/uncontrolled port, 77

AAA RADIUS session-control, 51

portal authentication user access, 114

cookie challenging

IPsec IKEv2, 283

IPsec IKEv2 cookie challenging, 289

copying

IPsec packet DF bit copy, 262

creating

AAA HWTACACS scheme, 35

AAA ISP domain, 45

AAA LDAP scheme, 43

AAA RADIUS scheme, 26

attack D&P defense policy, 358

connection limit policy, 349

local key pair, 199

security LDAP server, 41

CRL

PKI, 208

PKI architecture, 209

PKI CA policy, 209

PKI certificate export, 219

PKI certificate removal, 219

PKI certificate-based access control policy, 220

troubleshooting PKI CRL obtain failure, 239

crypto engine

IPsec, 246

customization

portal authentication page, 103

customization rules

portal authentication pages, 130

customizing

portal authentication pages, 130

security portal authentication pages, 130

DAE

AAA RADIUS DAE server (DAS), 52

data

SSL configuration, 336, 337

data encryption

PKI configuration, 208, 210, 221

defending

attack D&P defense policy, 358

attack D&P defense policy (flood), 360

attack D&P defense policy (scanning), 360

attack D&P defense policy (single-packet), 358

attack D&P defense policy configuration (ACK flood), 361

attack D&P defense policy configuration (DNS flood), 364

attack D&P defense policy configuration (FIN flood), 362

attack D&P defense policy configuration (HTTP flood), 364

attack D&P defense policy configuration (ICMP flood), 362

attack D&P defense policy configuration (ICMPv6 flood), 363

attack D&P defense policy configuration (RST flood), 362

attack D&P defense policy configuration (SYN flood), 360

attack D&P defense policy configuration (SYN-ACK flood), 361

attack D&P defense policy configuration (UDP flood), 363

attack D&P policy application (device), 365

attack D&P policy application (interface), 365

delimiter (802.1X domain name), 88

DES

IPsec encryption algorithm, 245

destination

portal authentication portal-free rule, 114

portal authentication subnet, 115

destroying

local key pair, 201

detecting

AAA RADIUS server status detection test profile, 25

ARP attack detection (source MAC-based), 372, 373

ARP attack detection configuration, 378

attack D&P detection exemption, 364

portal authentication detection features, 121

portal authentication server, 122

portal authentication server detection configuration, 162

portal authentication user online detection, 121

portal authentication user synchronization, 124

portal authentication Web server, 123

device

802.1X authentication, 81

802.1X authentication initiation, 80

802.1X client configuration, 91, 91, 94

802.1X configuration, 85

802.1X EAD assistant, 88

AAA configuration, 1, 17, 57

AAA device management user, 18

AAA HWTACACS accounting server, 36

AAA HWTACACS authentication server, 35

AAA HWTACACS authorization server, 36

AAA HWTACACS implementation, 7

AAA HWTACACS scheme, 35

AAA HWTACACS server SSH user, 57

AAA HWTACACS shared keys, 37

AAA implementation, 12

AAA LDAP attribute map for authorization, 44

AAA LDAP authentication server, 43

AAA LDAP authorization server, 44

AAA LDAP implementation, 9

AAA LDAP scheme, 40

AAA LDAP server SSH user authentication, 63

AAA LDAP server timeout period, 41

AAA local guest management, 72

AAA local user, 18

AAA RADIUS accounting server parameters, 27

AAA RADIUS authentication server, 26

AAA RADIUS implementation, 2

AAA RADIUS scheme, 25

AAA RADIUS server 802.1X user, 67

AAA RADIUS server SSH user authentication+authorization, 60

AAA RADIUS server status, 29

AAA RADIUS shared keys, 28

AAA scheme, 18

AAA SSH user local authentication+HWTACACS authorization+RADIUS accounting, 58

attack D&P configuration, 354, 358

attack D&P defense policy, 358

attack D&P device-preventable attacks, 354

attack D&P policy application (device), 365

authorized ARP (DHCP server), 376

connection limit configuration, 349, 352

MAC authentication, 97, 98

MAC authentication configuration, 97

password control configuration, 189, 191, 196

password control parameters (global), 193

password control parameters (local user), 194

password control parameters (super), 195

password control parameters (user group), 193

password setting, 189

portal authentication AAA server, 102

portal authentication client, 102

portal authentication configuration on VLAN interface, 147

portal authentication device access, 102

portal authentication extended configuration, 159

portal authentication policy server, 102

portal authentication server, 102

portal authentication server detection configuration, 162

portal authentication Web server, 102

SSH SCP client, 307

SSH SCP server enable, 297

SSH Secure Telnet client, 302

SSH Secure Telnet server connection establishment, 303

SSH Secure Telnet server enable, 297

SSH server configuration, 295

SSH SFTP client, 304

SSH SFTP server enable, 297

SSL server policy configuration, 337, 340

user profile, 183

user profile configuration, 183, 184

DF bit

IPsec packet DF bit clear, 262

IPsec packet DF bit copy, 262

IPsec packet DF bit set, 262

DH algorithm

IPsec IKE, 268

IPsec PFS, 268

DH guessing

IPsec IKEv2, 283

DHCP

authorized ARP (DHCP server), 376

authorized ARP (relay agent), 376

portal authentication mode, 104

portal authentication process, 105

dictionary

attack D&P login delay, 366

digital certificate

PKI CA certificate, 208

PKI CA policy, 209

PKI CA storage path, 218

PKI certificate export, 219

PKI certificate import/export, 232

PKI certificate obtain, 216

PKI certificate removal, 219

PKI certificate request, 213

PKI certificate request (automatic), 214

PKI certificate request (manual), 215

PKI certificate request abort, 215

PKI certificate verification, 217

PKI certificate-based access control policy, 220

PKI configuration, 208, 210, 221

PKI CRL, 208

PKI domain configuration, 211

PKI entity configuration, 210

PKI local certificate, 208

PKI OpenCA server certificate request, 228

PKI peer certificate, 208

PKI RA certificate, 208

PKI RSA Keon CA server certificate request, 221

PKI verification (CRL checking), 217

PKI verification (w/o CRL checking), 218

PKI Windows 2003 CA server certificate request, 224

Digital Signature Algorithm. Use DSA

directing

portal authentication Web redirect, 128

10-Security

Client/server model

Information exchange security mechanism

User authentication methods

RADIUS packet format

Extended RADIUS attributes

HWTACACS

LDAP directory service

LDAP authentication and authorization

Basic LDAP authorization process

AAA implementation on the device

User management based on ISP domains and user access types

AAA methods

Protocols and standards

Configuring AAA schemes

Local user configuration task list

Configuration task list

Creating a RADIUS scheme

Specifying the RADIUS authentication servers

Specifying the RADIUS accounting servers and the relevant parameters

Setting the username format and traffic statistics units

Setting RADIUS timers

Configuring the accounting-on feature

Configuring the Login-Service attribute check method for SSH, FTP, and terminal users

Creating an HWTACACS scheme

Specifying the shared keys for secure HWTACACS communication

Setting the username format and traffic statistics units

Creating an LDAP server

Configuring administrator attributes

Creating an ISP domain

Overview

Configuration procedure

Configuration prerequisites

Configuration guidelines

Configuration procedure

Configuration prerequisites

Configuration guidelines

Configuration procedure

Configuration prerequisites

Configuration procedure

Configuring the RADIUS DAS feature

Configuring a NAS-ID profile

AAA configuration examples

AAA for SSH users by an HWTACACS server

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

Authentication for SSH users by an LDAP server

Network requirements

Configuration procedure

Verifying the configuration

AAA for 802.1X users by a RADIUS server

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

RADIUS authentication failure

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Symptom

Analysis