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 1 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 a switch or a router. 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 2.

Figure 2 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 3 Portal support for EAP working flow diagram

As shown in Figure 3, 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 4 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, WX2500H series, and WX3000H 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
(Optional.) Configuring portal temporary pass
(Optional.) Configuring the portal authentication monitoring feature
(Optional.) Setting the user synchronization interval for portal authentication using OAuth

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
10. Enter system view.	system-view	N/A
11. Create a portal Web server and enter its view.	portal web-server server-name	By default, no portal Web servers exist.
12. Specify the URL of the portal Web server.	url url-string	By default, no URL is specified.
13. 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.
14. (Optional.) Specify the portal Web server type.	server-type { cmcc \| imc \| oauth }	By default, the portal Web server type is IMC.
15. (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.
16. (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.
17. Return to system view.	quit	N/A
18. (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.

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.

If any device in a VSRP group executes the portal delete-user command to log out a user, all devices in this group log out the user.

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:

· Master/backup device switchover.

· Active/standby MPU switchover.

· Disabling portal authentication on the interface.

· Breaking the data channel in the VSRP group.

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.

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 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 1). You can define the names of the files other than the main authentication page files. File names and directory names are case insensitive.

Table 1 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 }	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 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 2 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 2) 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

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 redirection URL for QQ authentication success.	redirect-url url-string	By default, the redirection URL for QQ authentication success is http://lvzhou.h3c.com/portal/qqlogin.html. 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.

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 \| 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 5, 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 5 Network diagram

Configuration prerequisites

· Configure IP addresses for the client, AC, and servers as shown in Figure 5 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 6.

c. Configure the portal server parameters as needed.

This example uses the default settings.

d. Click OK.

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

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

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 8 Adding a portal device

4. Associate the portal device with the IP address group:

a. As shown in Figure 9, 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 10.

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 9 Device list

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

VSRP instance : Not configured

VSRP state : N/A

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 11, 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 11 Network diagram

Configuration prerequisites

· Configure IP addresses for the client, AC, and servers as shown in Figure 11 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 12.

c. Configure the portal server parameters as needed.

This example uses the default settings.

d. Click OK.

Figure 12 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 13.

Figure 13 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 14.

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 14 Adding a portal device

4. Associate the portal device with the IP address group:

a. As shown in Figure 15, click the icon in the Port Group Information Management column of device NAS to enter the port group configuration page.

Figure 15 Device list

b. Click Add to enter the page shown in Figure 16.

Figure 16 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 WA4320i-ACN

[AC-wlan-ap-ap2] serial-id 210235A29G007C000020

# 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 17, 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 17 Network diagram

Configuration prerequisites

· Configure IP addresses for the client, AC, and servers as shown in Figure 17 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

VSRP instance : Not configured

VSRP state : N/A

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 18, 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 18 Network diagram

Configuration prerequisites and guidelines

· Configure IP addresses for the AC and servers as shown in Figure 18 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 19.

c. Configure the portal server heartbeat interval.

d. Use the default settings for other parameters.

e. Click OK.

Figure 19 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 20.

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

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 21 Adding a portal device

4. Associate the portal device with the IP address group:

a. As shown in Figure 22, 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 23.

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 22 Device list

Figure 23 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 24, 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 24 Network diagram

Configuration prerequisites and guidelines

· Configure IP addresses for the client, AC, and server as shown in Figure 24 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

VSRP instance: --

VSRP state: N/A

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 25, 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 25 Network diagram

Configuration prerequisites

· Configure IP addresses for the client, AC, and servers as shown in Figure 25 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 26.

c. Configure the portal server parameters as needed.

This example uses the default values.

d. Click OK.

Figure 26 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 27.

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

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 28 Adding a portal device

4. Associate the portal device with the IP address group:

a. As shown in Figure 29, click the Port Group Information Management icon for device NAS to enter the port group configuration page.

Figure 29 Device list

b. Click Add to enter the page shown in Figure 30.

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

c. Enter the access policy name.

d. Select a service group.

e. Use the default settings for other parameters.

f. Click OK.

Figure 31 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 32.

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

c. Select an access user.

d. Set the password.

e. Select a value from the Max. Transparent Portal Bindings list.

f. Click OK.

Figure 33 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 34.

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 34 Configuring user endpoint settings

e. click the Configure icon for Endpoint Aging Time to enter the page shown in Figure 35.

f. Set the endpoint aging time as needed.

This example uses the default value.

Figure 35 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 36, 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 36 Network diagram

Configuration prerequisites

· Configure IP addresses for the client and AC as shown in Figure 36 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 lcoal-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

Configuring portal support for QQ authentication

Network requirements

As shown in Figure 37, the AC acts as the DHCP server to assign a private IP address to the client. The client uses the private IP address to perform QQ authentication.

Configure portal support for QQ authentication to meet the following requirements:

· The client can access only the QQ authentication server before passing QQ authentication.

· The client can access other network resources after passing QQ authentication.

Figure 37 Network diagram

Configuration prerequisites

· Assign IP addresses to the client, AC, and QQ server as shown in Figure 37 and make sure they can reach each other.

· Make sure the AP can communicate with the AC.

· Edit portal authentication pages, and add the QQ authentication button to the logon page. Compress the authentication pages to a .zip file, and save the authentication page file to the root directory of the AC. This example uses file abc.zip.

Configuration procedure

1. Configure basic network functions:

# Create VLAN 100. The client will access the wireless network through VLAN 100.

<AC> system-view

[AC] vlan 100

[AC-vlan100] quit

# Create VLAN 200. The AC will use this VLAN for NAT and to obtain a public IP address through DHCP.

[AC] vlan 200

[AC-vlan200] quit

# Assign IP addresses to VLAN interfaces. (Details not shown.)

# Enable DNS proxy.

[AC] dns proxy enable

# Map IP address 192.168.1.1 to the domain name of the portal Web server lvzhou.h3c.com.

[AC] ip host lvzhou.h3c.com 192.168.1.1

# Enable DHCP.

[AC] dhcp enable

# Create a DHCP address pool named client.

[AC] dhcp server ip-pool client

# Configure DHCP address pool client to assign IP addresses to clients from subnet 192.168.1.0/24.

[AC-dhcp-pool-client] network 192.168.1.0 mask 255.255.255.0

# Exclude IP address 192.168.1.1.1 from dynamic allocation.

[AC-dhcp-pool-client] forbidden-ip 192.168.1.1

# Specify 192.168.1.1 as the gateway address.

[AC-dhcp-pool-client] gateway-list 192.168.1.1

# Specify 192.168.1.1 as the DNS server address.

[AC-dhcp-pool-client] dns-list 192.168.1.1

[AC-dhcp-pool-client] quit

# Apply DHCP address pool client to VLAN-interface 100.

[AC] interface vlan-interface 100

[AC-Vlan-interface100] dhcp server apply ip-pool client

[AC-Vlan-interface100] quit

# Configure ACL 2000, and create a rule to permit packets only from subnet 192.168.1.0/24 to pass through.

[AC] acl basic 2000

[AC-acl-ipv4-basic-2000] rule permit source 192.168.1.0 0.0.0.255

[AC-acl-ipv4-basic-2000] quit

# Configure VLAN-interface 200 to use DHCP for IP address acquisition.

[AC] interface vlan-interface 200

[AC-Vlan-interface200] ip address dhcp-alloc

# Enable outbound NAT with Easy IP on interface VLAN-interface 200.

[AC-Vlan-interface200] nat outbound 2000

2. Configure an authentication domain:

# Create an ISP domain named extend-auth.

[AC] domain extend-auth

# Configure the device not to perform authentication, authorization, or accounting for portal users.

[AC-isp-extend-auth] authentication portal none

[AC-isp-extend-auth] authorization portal none

[AC-isp-extend-auth] accounting portal none

[AC-isp-extend-auth] quit

3. Configure QQ authentication:

# Specify http:// 192.168.1.1/portal as the URL of the portal Web server.

[AC] portal web-server wbs

[AC-portal-websvr-wbs] url http://192.168.1.1/portal

[AC-portal-websvr-wbs] quit

# Create a QQ authentication server.

[AC] portal extend-auth-server qq

[AC-portal-extend-auth-server-qq] quit

# Create a service template named st1.

[AC] wlan service-template st1

# Assign clients coming online through service template st1 to VLAN 100.

[AC-wlan-st-st1] vlan 100

# Set the SSID of service template st1 to service.

[AC-wlan-st-st1] ssid service

# Enable portal authentication on service template st1.

[AC-wlan-st-st1] portal enable method direct

# Specify ISP domain extend-auth as the authentication domain for QQ authentication.

[AC-wlan-st-st1] portal extend-auth domain extend-auth

# Specify portal Web server wbs on service template st1.

[AC-wlan-st-st1] portal apply web-server wbs

# Enable service template st1.

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

[AC-wlan-st-st1] quit

# Create AP ap1 with model WA4320i-CAN, and set its serial ID to 210235A29G007C000020..

[AC] wlan ap ap1 model WA4320i-ACN

[AC-wlan-ap-ap1] serial-id 210235A29G007C000020

# Enter the view of radio 1.

[AC-wlan-ap-ap1] radio 1

# Bind service template st1 to radio 1.

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

# Enable radio 1.

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

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

[AC-wlan-ap-ap1] quit

# Create a local portal Web server and specify HTTP to exchange information with clients.

[AC] portal local-web-server http

# Specify the file abc.zip as the default authentication page file for local portal authentication. . (Make sure that the file exists under the root directory of the AC.)

[AC-portal-local-websvr-http] default-logon-page abc.zip

[AC-portal-local-websvr-http] quit

# Configure destination-based portal-free rules 1 and 2 to allow portal users to access the DNS service without authentication.

[AC] portal free-rule 1 destination ip any udp 53

[AC] portal free-rule 2 destination ip any tcp 53

# Configure destination-based portal-free rules 3 and 4 to allow portal users to access the QQ authentication server without authentication.

[AC] portal free-rule 3 destination *.qq.com

[AC] portal free-rule 4 destination *.gtimg.cn

Verifying the configuration

# Display information about the QQ authentication server.

[AC] display portal extend-auth-server all
Portal extend-auth-server: qq

Authentication URL : https://graph.qq.com

APP ID : 101235509

APP key : ******

Redirect URL : http://lvzhou.h3c.com/portal/qqlogin.html

Before passing the authentication, a user can access only the portal authentication page http://192.168.0.111/portal. All Web requests from the user will be redirected to the portal authentication page. After clicking the QQ authentication button on the portal authentication page, the user is redirected to the QQ authentication page. After passing QQ authentication, the user can access other network resources.

# Display information about all portal users.

[AC] display portal user all

Total portal users: 1

Username: 00-00-00-00-00-01

AP name: ap1

Radio ID: 1

SSID:service

Portal server: N/A

State: Online

VPN instance: N/A

MAC IP VLAN Interface

0015-e9a6-7cfe 192.168.1.2 100 WLAN-BSS1/0/1

Authorization information:

DHCP IP pool: N/A

User profile: N/A

ACL: N/A

Configuring portal support for email authentication

Network requirements

As shown in Figure 38, the AC acts as the DHCP server to assign a private IP address to the client. The client uses the private IP address to perform email authentication.

Configure portal support for email authentication to meet the following requirements:

· The client can access only the email authentication server before passing the authentication.

· The client can access other network resources after passing the authentication.

Figure 38 Network diagram

Configuration prerequisites

· Configure IP addresses for the client, AC, and email server as shown in Figure 38 and make sure they can reach each other.

· Make sure the AP can communicate with the AC.

· Edit portal authentication pages and the email authentication page, and add the email authentication button to the portal logon page. Compress the authentication pages to a .zip file, and save the authentication page file to the root directory of the AC. This example uses file abc.zip.

Configuration procedure

1. Configure basic network functions:

# Create VLAN 100. The client will access the wireless network through VLAN 100.

<AC> system-view

[AC] vlan 100

[AC-vlan100] quit

# Create VLAN 200. The AC will use VLAN 200 for NAT and to obtain a public network address through DHCP.

[AC] vlan 200

[AC-vlan200] quit

# Assign IP addresses to VLAN interfaces. (Details not shown.)

# Enable DNS proxy.

[AC] dns proxy enable

# Configure a mapping between the domain name of the portal Web server www.mail.com and IP address 192.168.1.1.

[AC] ip host www.mail.com 192.168.1.1

# Enable DHCP.

[AC] dhcp enable

# Create DHCP address pool named client.

[AC] dhcp server ip-pool client

# Configure DHCP address pool client to assign IP addresses to clients from subnet 192.168.1.0/24.

[AC-dhcp-pool-client] network 192.168.1.0 mask 255.255.255.0

# Exclude IP address 192.168.1.1 from dynamic allocation.

[AC-dhcp-pool-client] forbidden-ip 192.168.1.1

# Specify 192.168.1.1 as the gateway address.

[AC-dhcp-pool-client] gateway-list 192.168.1.1

# Specify 192.168.1.1 as the DNS server address.

[AC-dhcp-pool-client] dns-list 192.168.1.1

[AC-dhcp-pool-client] quit

# Apply DHCP address pool client to VLAN-interface 100.

[AC] interface vlan-interface 100

[AC-Vlan-interface100] dhcp server apply ip-pool client

[AC-Vlan-interface100] quit

# Configure ACL 2000, and create a rule to permit packets only from subnet 192.168.1.0/24 to pass through.

[AC] acl basic 2000

[AC-acl-ipv4-basic-2000] rule permit source 192.168.1.0 0.0.0.255

[AC-acl-ipv4-basic-2000] quit

# Configure VLAN-interface 200 to use DHCP for IP address acquisition.

[AC] interface vlan-interface 200

[AC-Vlan-interface200] ip address dhcp-alloc

# Enable outbound NAT with Easy IP on interface VLAN-interface 200.

[AC-Vlan-interface200] nat outbound 2000

[AC-Vlan-interface200] quit

2. Configure an ISP domain:

# Create an ISP domain named extend-auth.

[AC] domain extend-auth

# Configure the AC not to perform authentication, authorization, or accounting for portal users.

[AC-isp-extend-auth] authentication portal none

[AC-isp-extend-auth] authorization portal none

[AC-isp-extend-auth] accounting portal none

[AC-isp-extend-auth] quit

3. Configure email authentication:

# Specify https:// 192.168.1.1/portal as the URL of portal Web server wbs.

[AC] portal web-server wbs

[AC-portal-websvr-wbs] url https://192.168.1.1/portal

[AC-portal-websvr-wbs] quit

# Create an email authentication server.

[AC] portal extend-auth-server mail

# Specify POP3 and IMAP as protocols for email authentication.

[AC-portal-extend-auth-server-mail] mail-protocol pop3 imap

[AC-portal-extend-auth-server-mail] quit

# Create a service template named st1.

[AC] wlan service-template st1

# Assign clients coming online through service template st1 to VLAN 100.

[AC-wlan-st-st1] vlan 100

# Set the SSID of service template st1 to service.

[AC-wlan-st-st1] ssid service

# Enable portal authentication on service template st1.

[AC-wlan-st-st1] portal enable method direct

# Specify ISP domain extend-auth as the authentication domain for email authentication.

[AC-wlan-st-st1] portal extend-auth domain extend-auth

# Specify portal Web server wbs on service template st1.

[AC-wlan-st-st1] portal apply web-server wbs

# Enable service template st1.

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

[AC-wlan-st-st1] quit

# Create AP ap1 with model WA4320i-CAN, and set its serial ID to 210235A29G007C000020.

[AC] wlan ap ap1 model WA4320i-ACN

[AC-wlan-ap-ap1] serial-id 210235A29G007C000020

# Enter the view of radio 1.

[AC-wlan-ap-ap1] radio 1

# Bind service template st1 to radio 1.

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

# Enable radio 1.

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

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

[AC-wlan-ap-ap1] quit

# Create a local portal Web server and specify HTTP to exchange information with clients.

[AC] portal local-web-server https

# Specify the file abc.zip as the default authentication page file for local portal authentication. (Make sure that the file exists under the root directory of the AC.)

[AC-portal-local-websvr-https] default-logon-page abc.zip

[AC-portal-local-websvr-https] quit

# Configure destination-based portal-free rules 1 and 2 to allow portal users to access the DNS service without authentication.

[AC] portal free-rule 1 destination ip any udp 53

[AC] portal free-rule 2 destination ip any tcp 53

Verifying the configuration

# Display information about the email authentication server.

[AC] display portal extend-auth-server mail

Portal extend-auth-server: mail

Mail protocol : POP3 IMAP

Before passing the authentication, a user can access only the portal authentication page http://192.168.0.111/portal. All Web requests from the user will be redirected to the portal authentication page. After the user clicking the email authentication button on the portal authentication page, the user is redirected to the email authentication page. After passing the email authentication, the user can access other network resources.

# Display information about all portal users.

[AC] display portal user all

Total portal users: 1

Username: user

AP name: ap1

Radio ID: 1

SSID:service

Portal server: N/A

State: Online

VPN instance: N/A

MAC IP VLAN Interface

0015-e9a6-7cfe 192.168.1.2 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.

10-Security

Configuring portal authentication

Portal system components

Authentication client

Access device

Portal authentication server

Portal Web server

AAA server

Security policy server

Client and local portal Web server interaction protocols

Portal authentication mode

Portal support for EAP

Portal filtering rules

Configuration prerequisites

Configuring a portal Web server

Configuring a portal-free rule

Configuring an authentication destination subnet

Specifying a portal authentication domain

Configuring portal detection features

Configuring online detection of portal users

Configuring the portal fail-permit feature

Enabling portal roaming

Configuring Web redirect

Configuring the local portal Web server feature

Customizing authentication pages

File name rules

Page request rules

Post request attribute rules

Page file compression and saving rules

Enabling validity check on wireless clients

Editing a third-party authentication button on the logon page

Editing a third-party authentication page

Configuring a third-party authentication server

Configuring the QQ authentication server

Configuring the email authentication server

Portal configuration examples

Configuring portal authentication on a VLAN interface

Network requirements

Configuration prerequisites

Configuring the portal authentication server on IMC PLAT 5.0

Configuring the AC

Verifying the configuration

Configuring portal authentication on a service template

Network requirements

Configuration prerequisites

Configuring the portal server on IMC PLAT 5.0

Configuring the AC

Verifying the configuration

Network requirements

Configuration prerequisites

Configuration procedure

Verifying the configuration

Network requirements

Configuring the portal authentication server on IMC PLAT 5.0

Configuring the AC

Verifying the configuration

Network requirements

Configuration prerequisites and guidelines

Configuration procedure

Verifying the configuration

Network requirements

Configuration prerequisites

Configuration procedure

Verifying the configuration

Network requirements

Configuration prerequisites

Configuration procedure

Verifying the configuration

Network requirements

Configuration prerequisites

Configuration procedure

Verifying the configuration

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Symptom