13-User Access and Authentication Configuration Guide

HomeSupportResource CenterWirelessH3C WBC Series Multiservice Access ControllersH3C WBC Series Multiservice Access ControllersTechnical DocumentsConfigureConfiguration GuidesH3C WBC Series Multservice Access Controllers Configuration Guides(E5448)-6W10013-User Access and Authentication Configuration Guide
08-Portal configuration
Title Size Download
08-Portal configuration 1.36 MB

Contents

Configuring portal authentication· 1

About portal authentication· 1

Advantages of portal authentication· 1

Extended portal functions· 1

Portal system·· 1

Portal authentication using a remote portal server 2

Local portal service· 3

Portal authentication modes· 3

Portal authentication process· 4

Portal support for EAP· 5

Portal filtering rules· 5

Portal support for BYOD·· 6

MAC-based quick portal authentication· 6

Portal authentication configuration in wireless networks· 7

Inter-AC roaming for portal users· 7

Restrictions and guidelines: Portal configuration· 9

Portal authentication tasks at a glance· 9

Prerequisites for portal authentication· 11

Configuring a remote portal authentication server 11

Configuring a portal Web server 12

Portal Web server tasks at a glance· 12

Configure basic parameters for a portal Web server 12

Enabling base64 encoding for the user IP address in redirection URLs· 13

Enabling the captive-bypass feature· 14

Configuring a match rule for URL redirection· 15

Configuring the unescaped special characters in portal Web server URLs redirected to users· 15

Configuring the local portal service features· 16

About the local portal service· 16

Restrictions and guidelines for configuring local portal service features· 16

Customizing authentication pages· 16

Configuring a local portal Web service· 18

Configuring the User-Agent match string· 19

Enabling portal authentication on an interface· 20

Specifying a portal Web server on an interface· 20

Enabling portal authentication on a service template· 20

Specifying a portal Web server on a service template· 21

Specifying a portal authentication domain· 21

About portal authentication domains· 21

Restrictions and guidelines for specifying a portal authentication domain· 21

Specifying a portal authentication domain on an interface· 22

Specifying an IPv4 portal authentication domain on a service template· 22

Controlling portal user access· 22

Configuring a portal-free rule· 22

Configuring an authentication destination subnet 23

Configuring a portal-forbidden rule· 24

Configuring support of portal authentication for dual stack· 25

Setting the maximum number of portal users· 26

Enabling strict-checking on portal authorization information· 27

Allowing only users with DHCP-assigned IP addresses to pass portal authentication· 28

Enabling outgoing packets filtering· 29

Enabling intra-VLAN roaming for portal users· 29

Configuring inter-AC roaming for portal users· 30

Configuring the portal fail-permit feature· 31

Configuring the NAS-Port-Type attribute· 32

Enabling validity check on wireless clients· 32

Configuring portal detection features· 33

Configuring online detection of portal users· 33

Configuring portal authentication server detection· 34

Configuring portal Web server detection· 35

Enabling DHCP packet capture· 36

Configuring portal user synchronization· 36

Configuring portal packet attributes· 37

Configuring the BAS-IP or BAS-IPv6 attribute· 37

Specifying the device ID·· 38

Configuring attributes for RADIUS packets· 38

Specifying a format for the NAS-Port-Id attribute· 38

Applying a NAS-ID profile to an interface· 39

Setting the user traffic backup threshold· 40

Configuring MAC-based quick portal authentication· 40

Restrictions and guidelines for configuring MAC-based quick portal authentication· 40

Configuring a remote MAC binding server 40

Configuring a local MAC binding server 41

Specifying a MAC binding server on an interface· 42

Specifying a MAC binding server on a service template· 42

Configure cloud MAC-trigger authentication· 43

Disabling the Rule ARP or ND entry feature for portal clients· 43

Disabling traffic accounting for portal users· 43

Logging out online portal users· 44

Automatically logging out wireless portal users· 44

Kicking out a user after the user passes portal authentication· 45

Configuring Web redirect 45

About Web redirect 45

Configuring destination-based portal redirection rules· 45

Configuring Web redirect on an interface· 46

Configuring Web redirect on a service template· 46

Configuring portal safe-redirect 47

Setting the maximum number of portal redirect sessions for a single user 48

Setting the interval at which an AP reports traffic statistics to the AC· 49

Excluding an attribute from portal protocol packets· 49

Configuring support of portal authentication for third-party authentication· 50

About third-party authentication· 50

Restrictions and guidelines for third-party authentication· 50

Editing buttons and pages for third-party authentication· 50

Configuring QQ authentication· 51

Configuring email authentication· 52

Configuring WeChat authentication· 52

Configuring Facebook authentication· 53

Specifying an authentication domain for third-party authentication· 54

Specifying the AC's interface for portal clients to access during third-party authentication· 55

Configuring portal temporary pass· 55

Setting the user synchronization interval for portal authentication using OAuth· 56

Configuring user synchronization for portal authentication using the WiFiDog protocol 56

Configuring portal authentication information report interval 57

Enabling portal logging· 57

Configuring the portal authentication monitoring feature· 58

Logging out wireless portal users that switch SSIDs· 59

Display and maintenance commands for portal 59

Portal configuration examples· 62

Example: Configuring direct portal authentication on a VLAN interface· 62

Example: Configuring direct portal authentication on a service template· 68

Example: Configuring extended direct portal authentication· 71

Example: Configuring portal server detection· 75

Example: Configuring direct portal authentication using a local portal Web service· 80

Example: Configuring remote MAC-based quick portal authentication· 83

Example: Configuring local MAC-based quick portal authentication· 91

Example: Configuring cloud MAC-trigger authentication· 94

Example: Configuring portal support for QQ authentication· 97

Example: Configuring portal support for email authentication· 100

Example: Configuring portal inter-AC roaming· 103

Troubleshooting portal 110

No portal authentication page is pushed for users· 110

Cannot log out portal users on the access device· 110

Cannot log out portal users on the RADIUS server 111

Users logged out by the access device still exist on the portal authentication server 111

 


Configuring portal authentication

About portal authentication

Portal authentication controls user access to networks. Portal authenticates a user by the username and password the user enters on a portal authentication page. Typically, portal authentication is deployed on the access layer and vital data entries.

In a portal-enabled network, users can actively initiate portal authentication by visiting the authentication website provided by the portal Web server. Or, they are redirected to the portal authentication page for authentication when they visit other websites.

The device supports Portal 1.0, Portal 2.0, and Portal 3.0.

Advantages of portal authentication

Portal authentication has the following advantages:

·     Allows users to perform authentication through a Web browser 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.

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 network resources after passing security check.

Security check must cooperate with the H3C IMC security policy server and the iNode client.

Portal system

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

 

Authentication client

An authentication client is a Web browser that runs HTTP/HTTPS or a user host that runs a portal client. Security check for the user host is implemented through the interaction between the portal client and the security policy server. Only the H3C iNode client is supported.

Access device

An access device provides access services. It has the following functions:

·     Redirects all HTTP or HTTPS 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 network resources.

Portal server

A portal server collectively refers to a portal authentication server and 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 portal authentication server receives authentication requests from authentication clients and interacts with the access device to authenticate users. The portal Web server is typically integrated with the portal authentication server and it can also be 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. Only hosts that run portal clients can interact with the security policy server.

Portal authentication using a remote portal server

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

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.

Local portal service

System components

As shown in Figure 2, a local portal system consists of an authentication client, access device, and AAA server. The access device acts as both the portal Web server and the portal authentication server to provide the local portal Web service for the authentication client. The authentication client can only be a Web browser, and it cannot be a user host that runs a portal client. Therefore, extended portal functions are not supported and no security policy server is required.

Figure 2 System components

 

Portal page customization

To provide the local portal web service, you must customize a set of authentication pages that the device will push to users. 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. On the device, you must specify one of the files as the default authentication page file by using the default-logon-page command.

For more information about authentication page customization, see "Customizing authentication pages."

Portal authentication modes

Direct authentication

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. The process of direct authentication is simpler than that of re-DHCP authentication.

Portal authentication process

Direct authentication process (with CHAP/PAP authentication)

Figure 3 Direct authentication process

 

The direct authentication process is as follows:

1.     A portal user access the Internet through HTTP or HTTPS, and the HTTP or HTTPS 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 support for EAP

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.

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 4 Portal support for EAP working flow diagram

 

As shown in Figure 4, 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.

Portal filtering rules

The access device uses portal filtering rules to control user traffic forwarding.

Based on the configuration and authentication status of portal users, the device generates the following categories of portal filtering rules:

·     First category—The rule permits user packets that are destined for the portal Web server and packets that match the portal-free rules to pass through.

·     Second category—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.

The device supports the following types of authorization ACLs:

¡     Basic ACLs (ACL 2000 to ACL 2999).

¡     Advanced ACLs (ACL 3000 to ACL 3999).

For an authorization ACL to take effect, make sure the ACL exists and has ACL rules excluding rules configured with the counting, established, fragment, source-mac, or logging keyword. For more information about ACL rules, see ACL commands in Security Command Reference.

·     Third category—The rule redirects all HTTP or HTTPS requests from unauthenticated users to the portal Web server.

·     Fourth category—For direct authentication, the rule forbids any user packets to pass through.

After receiving a user packet, the device compares the packet against the filtering rules from the first category to the fourth category. Once the packet matches a rule, the matching process completes.

Portal support for BYOD

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

Only direct authentication supports MAC-based quick portal authentication.

The authentication is implemented as follows:

1.     When a user accesses the network for the first time, 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 the MAC address of the user is bound with a portal user account.

¡     If a matching MAC-account binding 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 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 sends the user's MAC address and authentication information to the MAC binding server for MAC-account binding. Additionally, the access device deletes the MAC-trigger entry of the user.

 

 

NOTE:

·     In wireless networks where APs are configured to forward client data traffic, APs report traffic statistics to the AC at regular intervals. The AC can determine whether a user's traffic exceeds 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 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 access configuration in WLAN Access Configuration Guide.

Inter-AC roaming for portal users

This feature allows portal users that have been authenticated on an AC to roam to another AC so as to access the network resources without re-authentication.

In inter-AC roaming, the following roles are involved:

·     WLAN roaming center—Manages authentication, authorization, and roaming information of wireless portal users and provides user query service.

·     Portal roaming centers—Provide authentication and roaming services.

As shown in Figure 5, AC 1 acts as the WLAN roaming center. AC 2 and AC 3 act as portal roaming centers.

Figure 5 Inter-AC roaming of portal users

 

The client first comes online on AC 2, roams to AC 3, and then goes offline, as follows:

1.     The client comes online on AC 2:

a.     When the client requests to come online, AC 2 sends a user query request to AC 1.

b.     AC 1 sends a user query response to AC 2 to notify AC 2 that no matching portal user has been found.

c.     AC 2 performs portal authentication on the client.

d.     After the client passes portal authentication, AC 2 sends a user online packet to AC 1 to notify AC 1 that the client has come online. The user online packet includes authorization information that the AAA server assigns to the client.

e.     Upon receiving the user online packet, AC 1 creates a user entry for the client and then sends a user online response to AC 2. The user entry includes the IP address, MAC address, access device list, authorization information, and roaming information of the client.

2.     The client roams from AC 2 to AC 3:

a.     When the client requests to come online on AC 3, AC 3 sends a user query request to AC 1.

b.     AC 1 sends a user query response to AC 3 to notify AC 3 that a matching user has been found. The user query response includes the authorization information that the user obtained when it came online through AC 2.

c.     Upon receiving the user query response, AC 3 allows the client to come online without authentication and then sends a user online packet to AC 1.

d.     Upon receiving the user online packet, AC 1 updates the roaming information in the user entry for the client and then sends a user online response to AC 3.

3.     The client requests to go offline or the client is forcibly logged out by AC 3:

¡     If the client requests to go offline, the AC through which the client comes online for the first time (AC 2) starts the offline process.

When the client requests to go offline, AC 2 deletes the user and sends a user offline packet to AC 1. Upon receiving the user offline packet, AC 1 removes AC 2 from the access device list of the user entry. It also sends a user offline packet to the other access devices (in this example, AC 3) in the list. Upon receiving the user offline packet, AC 3 deletes the user entry and sends a user offline response to AC 1.

¡     If the client is forcibly logged out by AC 3, AC 3 sends a user offline packet to AC 1. Upon receiving the user offline packet, AC 1 deletes AC 3 from the access device list of the user entry and sends a user offline response to AC 3.

The reasons that a portal user is forcibly logged out include the following:

¡     The administrator executes a command on the access device to log out the user.

¡     The AP through which the user accesses the WLAN goes offline.

¡     The DHCP lease of the user expires.

¡     The authorization idle timeout timer or the authorization session timeout timer of the user expires.

¡     The administrator logs out the user on the AAA server.

Restrictions and guidelines: Portal configuration

The device processes user traffic that matches a rule in the authorization ACL based on the permit or deny statement of the rule. If the user traffic does not match any authorization ACL rules, the device performs different actions for different type of portal users:

·     For preauthentication users, the device pushed the authentication page.

·     For authenticated users, the device permits all packets of the users.

If the traffic of a portal user does not match any rule in the authorization ACL of the authentication domain, the device permits the traffic. To deny such traffic, configure the last rule in the ACL to deny all packets by using the rule deny ip command.

Make sure the authorization ACLs assigned to portal users do not have rules specified with a source IPv4, IPv6, or MAC address. Otherwise, the users cannot come online after passing authentication. For more information about authorization ACLs, see authorization attribute configuration in "Configuring AAA."

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

Portal authentication through Web does not support security check for users. To implement security check, the client must be the H3C iNode client.

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 tasks at a glance

To configure portal authentication, perform the following tasks:

1.     Configuring a remote portal service

Perform this task if a remote portal server is used.

¡     Configuring a remote portal authentication server

¡     Configuring a portal Web server

2.     Configuring a local portal service

Perform this task if the access device acts as a portal authentication server and portal Web server.

¡     Configuring the local portal service features

¡     Configuring a portal Web server

3.     Enabling portal authentication and specifying a portal Web server

Choose the options to configure on an interface or service template.

¡     Enabling portal authentication on an interface

¡     Specifying a portal Web server on an interface

¡     Enabling portal authentication on a service template

¡     Specifying a portal Web server on a service template

4.     (Optional.) Specifying a portal authentication domain

5.     (Optional.) Controlling portal user access

¡     Configuring a portal-free rule

¡     Configuring an authentication destination subnet

¡     Configuring a portal-forbidden rule

¡     Configuring support of portal authentication for dual stack

¡     Setting the maximum number of portal users

¡     Enabling strict-checking on portal authorization information

¡     Allowing only users with DHCP-assigned IP addresses to pass portal authentication

¡     Enabling outgoing packets filtering

¡     Enabling intra-VLAN roaming for portal users

¡     Configuring inter-AC roaming for portal users

¡     Configuring the portal fail-permit feature

¡     Configuring the NAS-Port-Type attribute

¡     Enabling validity check on wireless clients

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

7.     (Optional.) Configuring attributes for portal packets and RADIUS packets

¡     Configuring portal packet attributes

You can configure the BAS-IP or BAS-IPv6 attribute for portal packets and specify the device ID.

¡     Configuring attributes for RADIUS packets

You can configure the NAS-Port-Id attribute format and apply a NAS-ID profile to an interface.

8.     (Optional.) Setting the user traffic backup threshold

9.     (Optional.) Configuring MAC-based quick portal authentication

a.     Configuring a remote MAC binding server

b.     Configuring a local MAC binding server

c.     Specifying a MAC binding server on an interface

d.     Specifying a MAC binding server on a service template

e.     Configure cloud MAC-trigger authentication

10.     (Optional.) Disabling the Rule ARP or ND entry feature for portal clients

11.     (Optional.) Disabling traffic accounting for portal users

12.     (Optional.) Configuring online and offline related features for portal users

¡     Logging out online portal users

¡     Automatically logging out wireless portal users

¡     Kicking out a user after the user passes portal authentication

13.     (Optional.) Configuring extended portal authentication features

¡     Configuring Web redirect

¡     Configuring portal safe-redirect

¡     Setting the maximum number of portal redirect sessions for a single user

¡     Setting the interval at which an AP reports traffic statistics to the AC

¡     Excluding an attribute from portal protocol packets

¡     Configuring support of portal authentication for third-party authentication

¡     Setting the user synchronization interval for portal authentication using OAuth

¡     Configuring portal authentication information report interval

¡     Logging out wireless portal users that switch SSIDs

14.     (Optional.) Monitoring portal authentication

¡     Enabling portal logging

¡     Configuring the portal authentication monitoring feature

Prerequisites for portal authentication

The portal feature provides a solution for user identity authentication and security check. To complete user identity authentication, portal must cooperate with RADIUS.

Before you configure portal, you must complete the following tasks:

·     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 remote portal authentication server

About this task

With portal authentication enabled, the device searches for a portal authentication server for a received portal request packet according to the source IP address information of the packet.

·     If a matching portal authentication server is found, 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 no matching portal authentication server is found, the device drops the packet.

Restrictions and guidelines

Do not delete a portal authentication server in use. Otherwise, users authenticated by that server cannot log out correctly.

Procedure

1.     Enter system view.

system-view

2.     Create a portal authentication server and enter its view.

portal server server-name

You can create multiple portal authentication servers.

3.     Specify the IP address of the portal authentication server.

IPv4:

ip ipv4-address [ key { cipher | simple } string ]

IPv6:

ipv6 ipv6-address [ key { cipher | simple } string ]

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.

The specified server type must be the same as the type of the portal authentication server actually used.

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

7.     (Optional.) Configure the device to periodically register with the portal authentication server.

server-register [ interval interval-value ]

By default, the device does not register with a portal authentication server.

Configuring a portal Web server

Portal Web server tasks at a glance

To configure a portal Web server, perform the following tasks:

1.     Configure basic parameters for a portal Web server

2.     (Optional.) Enabling base64 encoding for the user IP address in redirection URLs

3.     (Optional.) Enabling the captive-bypass feature

4.     (Optional.) Configuring a match rule for URL redirection

5.     (Optional.) Configuring the unescaped special characters in portal Web server URLs redirected to users

Configure basic parameters for a portal Web server

1.     Enter system view.

system-view

2.     Create a portal Web server and enter its view.

portal web-server server-name

You can create multiple portal Web servers.

3.     Specify the URL of the portal Web server.

url url-string

By default, no URL is specified for a portal Web server.

4.     Configure the parameters to be carried in the URL when the device redirects it to users.

url-parameter param-name { nas-id | nas-port-id | original-url | source-address | ssid | { ap-mac | source-mac } [ format section { 1 | 3 | 6 } { lowercase | uppercase } ] [ encryption { aes | des } key { cipher | simple } string ] | value expression | vlan }

By default, no redirection URL parameters are configured.

5.     (Optional.) Specify the portal Web server type.

server-type { cmcc | imc | ise | oauth | wifidog }

By default, the portal Web server type is IMC.

This configuration is applicable to only to the remote portal service.

The specified server type must be the same as the type of the portal Web server actually used.

Enabling base64 encoding for the user IP address in redirection URLs

About this task

During OAuth-based local portal WeChat authentication, if the redirection URL for portal users carries a user IP address, the WeChat authentication server might fail to identify the user IP address. This will cause portal authentication page push failure. To resolve this issue, perform this task so the device will perform base64 encoding on the user IP address in redirection URLs. In this way, the WeChat authentication server can parse the redirection URL and can correctly push portal authentication pages.

Restrictions and guidelines

Use this command only when the following conditions are met:

·     OAuth-based local portal WeChat authentication is used.

·     The user IP address parameter is carried in the URL of a portal Web server by specifying the source-address parameter in the url-parameter command.

Enabling base64 encoding on an interface

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Enable base64 encoding for the user IP address in redirection URLs on the interface.

portal url-param source-address code-base64

By default, base64 encoding is disabled for the user IP address in redirection URLs on an interface.

Enabling base64 encoding on a service template

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Enable base64 encoding for the user IP address in redirection URLs on the service template.

portal url-param source-address code-base64

By default, base64 encoding is disabled for the user IP address in redirection URLs on a service template.

Enabling the captive-bypass feature

About this task

Typically, when iOS mobile devices or some Android mobile devices are connected a portal-enabled network, the device pushes the authentication page to the mobile devices.

The captive-bypass feature enables the device to push the portal authentication page to the iOS and Android devices only when the users access the Internet by using a browser. If the users do not perform authentication but press the home button to return to the desktop, the Wi-Fi connection is terminated. To maintain the Wi-Fi connection in such cases, you can enable the optimized captive-bypass feature.

When optimized captive-bypass is enabled, the portal authentication page is automatically pushed to iOS mobile devices after they connects 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.

When an iOS client is connected to a network, it automatically sends a server reachability detection packet to determine whether the Apple server is reachable. If the server is reachable, the Wi-Fi connection displays connected. If the server is not reachable, the Wi-Fi connection is terminated.

When the network condition is poor, the device cannot detect a server reachability detection packet from an iOS mobile client within the captive-bypass detection timeout time. The client cannot receive a response for the server reachability detection packet, and therefore it determines the server to be unreachable and terminates the Wi-Fi connection. To avoid Wi-Fi disconnections caused by server reachability detection failure, set a longer captive-bypass detection timeout time when the network condition is poor.

Procedure

1.     Enter system view.

system-view

2.     Enter portal Web server view.

portal web-server server-name

3.     Enable the captive-pass feature.

captive-bypass [ android | ios [ optimize ] ] enable

By default, the captive-bypass feature is disabled. The device automatically pushes the portal authentication page to iOS mobile devices and some Android mobile devices when they are connected to a portal-enabled network.

4.     (Optional.) Set the captive-bypass detection timeout time.

a.     Return to system view.

quit

b.     Set the captive-bypass detection timeout time.

portal captive-bypass optimize delay seconds

By default, the captive-bypass detection timeout time is 6 seconds.

Configuring a match rule for URL redirection

About this task

A URL redirection match rule matches HTTP or HTTPS requests by user-requested URL or User-Agent information, and redirects the matching HTTP or HTTPS requests to the specified redirection URL.

For a portal Web server, you can configure the url command and the if-match command for URL redirection. 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.

Restrictions and guidelines

For a user to successfully access a redirection URL, configure a portal-free rule to allow HTTP or HTTPS requests destined for the redirection URL to pass. For information about configuring portal-free rules, see the portal free-rule command.

If both the url and if-match commands are executed, the if-match command takes priority to perform URL redirection.

If both portal safe-redirect and URL redirection match rules are configured, the device preferentially uses URL redirection match rules to perform URL redirection.

Procedure

1.     Enter system view.

system-view

2.     Enter portal Web server view.

portal web-server server-name

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

Configuring the unescaped special characters in portal Web server URLs redirected to users

About this task

By default, the device escapes all special characters in the portal Web server URL redirected to users (converts them to secure forms) to prevents the clients from misunderstanding the original semantics.

Some portal Web servers cannot identify the escape characters of some special characters, so they cannot correctly provide the Web authentication page to users. To resolve this issue, you can execute this command to unescape these special characters.

Prerequisites

Before configuring special characters, identify whether the portal Web server can recognize the escape characters of these special characters.

Procedure

1.     Enter system view.

system-view

2.     Configure the unescaped special characters in portal Web server URLs redirected to users.

portal url-unescape-chars character-string

By default, the device escapes all special characters in portal Web server URLs redirected to users.

Configuring the local portal service features

About the local portal service

After a local portal service is configured, the device acts as the portal Web server and portal authentication server to perform portal authentication on users. The portal authentication page file is saved in the root directory of the device.

Restrictions and guidelines for configuring local portal service features

For an interface to use the local portal service, the URL of the portal Web server specified for the interface must meet the following requirements:

·     The IP address in the URL must be the IP address of a Layer 3 interface (except 127.0.0.1) on the device, and the IP address must be reachable to portal clients.

·     The URL must be ended with /portal/. For example: http://1.1.1.1/portal/.

You must customize the authentication pages and upload them to the device.

In wireless networks, you can bind different authentication pages for portal users that belong to different SSIDs and use different device types (such as iPhone and Samsung). The system selects the authentication pages in the following order:

1.     Authentication pages bound to the SSID or device type.

2.     Default authentication pages.

Customizing authentication pages

About this task

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

A local portal Web service 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 access device.

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

<form action=logon.cgi method = post >

<p>User name:<input type="text" name = "PtUser" style="width:160px;height:22px" maxlength=64>

<p>Password :<input type="password" name = "PtPwd" style="width:160px;height:22px" maxlength=32>

<p><input type=SUBMIT value="Logon" name = "PtButton" style="width:60px;" onclick="form.action=form.action+location.search;">

</form>

3.     Authentication pages logonSuccess.htm and online.htm must contain the logoff Post request.

The following example shows part of the script in page online.htm.

<form action=logon.cgi method = post >

<p><input type=SUBMIT value="Logoff" name="PtButton" style="width:60px;">

</form>

Page file compression and saving rules

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.

·     The authentication pages must be placed in the root directory of the zip file.

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

   1     -rw-      1405  Feb 28 2008 15:53:20   ssid1.zip

   0     -rw-      1405  Feb 28 2008 15:53:31   ssid2.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:

    <form method=post action=logon.cgi target="_blank">

2.     Add the function for page loading pt_init() to LogonSuccess.htm.

See the contents in gray:

    <html>

    <head>

    <title>LogonSuccess</title>

    <script type="text/javascript" language="javascript" src="pt_private.js"></script>

    </head>

    <body onload="pt_init();" onbeforeunload="return pt_unload();">

    ... ...

    </body>

</html>

Configuring a local portal Web service

Prerequisites

Before you configure an HTTPS-based local portal Web service, you must complete the following tasks:

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

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 more information about SSL server policy configuration, see "Configuring SSL."

Procedure

1.     Enter system view.

system-view

2.     Create an HTTP- or HTTPS-based local portal Web service and enter its view.

portal local-web-server { http | https [ ssl-server-policy policy-name ] [ tcp-port port-number ] }

3.     Specify the default authentication page file for the local portal Web service.

default-logon-page filename

By default, file defaultfile.zip is specified as the default authentication page file for a local portal Web service.

4.     (Optional.) Configure the listening TCP port for the local portal Web service.

tcp-port port-number

By default, the HTTP service listening port number is 80 and the HTTPS service listening port number is the TCP port number set by the portal local-web-server command.

5.     (Optional.) Bind an SSID or endpoint type 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 SSID or endpoint type is bound to an authentication page file.

6.     (Optional.) Enable local portal user password modification.

user-password modify enable

By default, local portal user password modification is disabled.

7.     Configure the redirect URL for authentication success.

login success-url url-string

By default, no redirection URL for authentication success is configured.

8.     Configure the redirect URL for authentication failure.

login failed-url url-string

By default, no redirection URL for authentication failure is configured.

Configuring the User-Agent match string

About this task

When portal users use third-party software to perform portal authentication, the device checks the User-Agent string in portal authentication requests. If the User-Agent string does not include the match string specified on the device, users will fail portal authentication.

The User-Agent string includes hardware vendor, software operating system, browser, and search engine information. Perform this task to specify a string that can match the User-Agent information of the third-party software, so users can pass portal authentication by using that third-party software. For example, for users to pass portal authentication by following a WeChat official account, configure the User-Agent match string on the device as MicroMessenger.

Procedure

1.     Enter system view.

system-view

2.     Enter local portal Web service view.

portal local-web-server { http | https [ ssl-server-policy policy-name ] [ tcp-port port-number ] }

3.     Configure the User-Agent match string.

user-agent user-agent-string

By default, the User-Agent match string is MicroMessenger.

Enabling portal authentication on an interface

Restrictions and guidelines

When you enable portal authentication on an interface, follow these restrictions and guidelines:

·     Do not enable portal authentication on both an interface and a service template.

·     You can enable both IPv4 portal authentication and IPv6 portal authentication on an interface.

Procedure

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Enable portal authentication.

IPv4:

portal enable method direct

IPv6:

portal ipv6 enable method direct

By default, portal authentication is disabled.

Specifying a portal Web server on an interface

About this task

With a portal Web server specified on an interface, the device redirects the HTTP requests of portal users on the interface to the portal Web server.

You can specify both an IPv4 portal Web server and an IPv6 portal Web server on an interface.

Procedure

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Specify a portal Web server on the interface.

portal [ ipv6 ] apply web-server server-name [ secondary ]

By default, no portal Web servers are specified on an interface.

Enabling portal authentication on a service template

Restrictions and guidelines

Do not enable portal authentication on both an interface and a service template.

Only direct portal authentication is supported on a service template.

When local forwarding is used in wireless networks, enable validity check on wireless clients.

Procedure

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Enable direct portal authentication on the service template.

portal [ ipv6 ] enable method direct

By default, direct portal authentication is disabled on a service template.

Specifying a portal Web server on a service template

About this task

With a portal Web server specified, the device redirects HTTP requests from portal users on WLAN-BSS interfaces bound to the specified service template to the specified portal Web server.

Procedure

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Specify a portal Web server on the service template.

portal [ ipv6 ] apply web-server server-name [ secondary ]

By default, no portal Web server is specified on a service template.

Specifying a portal authentication domain

About portal authentication domains

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 an authentication domain specified on an interface or service template, the device uses the authentication domain for AAA of portal users. This allows for flexible portal access control.

Restrictions and guidelines for specifying a portal authentication domain

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.

If the chosen domain does not exist on the device, the device searches for the ISP domain configured to accommodate users assigned to nonexistent domains. If no such ISP domain is configured, user authentication fails. For information about ISP domains, see "Configuring AAA."

Specifying a portal authentication domain on an interface

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Specify an portal authentication domain on the interface.

portal [ ipv6 ] domain domain-name

By default, no portal authentication domain is specified on an interface.

You can specify both an IPv4 portal authentication domain and an IPv6 portal authentication domain on an interface.

Specifying an IPv4 portal authentication domain on a service template

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Specify a portal authentication domain on the service template.

portal [ ipv6 ] domain domain-name

By default, no portal authentication domain is specified on a service template.

Controlling portal user access

Configuring a portal-free rule

About this task

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 host name, 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.

Restrictions and guidelines for configuring a portal-free rule

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.

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 performing accounting on traffic of the users.

Configuring an IP-based portal-free rule

1.     Enter system view.

system-view

2.     Configure an IP-based portal-free rule.

IPv4:

portal free-rule rule-number { destination ip { ipv4-address { mask-length | mask } | any } [ tcp tcp-port-number | udp udp-port-number ] | source ip { ipv4-address { mask-length | mask } | any } [ tcp tcp-port-number | udp udp-port-number ] } * [ interface interface-type interface-number ]

IPv6:

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 IP-based portal-free rules are configured.

Configuring a source-based portal-free rule

1.     Enter system view.

system-view

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 rules are configured.

The vlan vlan-id option takes effect only on portal users that access the network through VLAN interfaces.

Configuring a destination-based portal-free rule

1.     Enter system view.

system-view

2.     Configure a destination-based portal-free rule.

portal free-rule rule-number destination host-name

By default, no destination-based portal-free rules are configured.

Configuring a description for a portal-free rule

1.     Enter system view.

system-view

2.     Configure a description for a portal-free rule.

portal free-rule rule-number description text

By default, no description is configured for a portal-free rule.

Configuring an authentication destination subnet

About this task

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.

Restrictions and guidelines

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.

Procedure

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Configure a portal authentication destination subnet.

IPv4:

portal free-all except destination ipv4-network-address { mask-length | mask }

IPv6:

portal ipv6 free-all except destination ipv6-network-address prefix-length

By default, users accessing any subnets must pass portal authentication.

Configuring a portal-forbidden rule

About this task

Portal-forbidden rules are used to filter user packets from the specified sources or destined for the specified destinations. The device drops HTTP or HTTPS packets that match the portal-forbidden rules.

Restrictions and guidelines

In a portal-forbidden rule, the source and destination IP addresses must be of the same IP type, and the source and destination ports must be of the same transport protocol type.

You can configure multiple portal-forbidden rules.

If the source or destination information in a portal-free rule and that in a portal-forbidden rule overlap, the portal-forbidden rule takes effect.

If you specify a destination host name in a portal-forbidden rule, the device drops users' DNS query packets for the specified host name. In addition, if a DNS server is correctly configured on the device, the device also drops user packets destined for the IP address resolved from the specified host name. If the DNS server is not correctly configured, the rule does not take effect on user packets destined for that IP address.

Procedure

1.     Enter system view.

system-view

2.     Configure a portal-forbidden rule.

IPv4:

portal forbidden-rule rule-number [ source { ip { ipv4-address { mask-length | mask } | any } [ tcp tcp-port-number | udp udp-port-number ] | ssid ssid-name } * ] destination { host-name | ip { ipv4-address { mask-length | mask } | any } [ tcp tcp-port-number | udp udp-port-number ] }

IPv6:

portal forbidden-rule rule-number [ source { ipv6 { ipv6-address prefix-length | any } [ tcp tcp-port-number | udp udp-port-number ] | ssid ssid-name } * ] destination { host-name | ipv6 { ipv6-address prefix-length | any } [ tcp tcp-port-number | udp udp-port-number ] }

By default, portal-forbidden rules are configured.

Configuring support of portal authentication for dual stack

About this task

Typically, IPv4 portal users can access only the IPv4 network after passing portal authentication, and IPv6 portal users can access only the IPv6 network after passing portal authentication. To allow portal users to access both IPv4 and IPv6 networks after passing one type (IPv4 or IPv6) of portal authentication, enable the portal dual-stack feature.

Configuring support of portal authentication for dual stack on an interface

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Enable the portal dual-stack feature on the interface.

portal dual-stack enable

By default, the portal dual-stack feature is disabled on an interface.

4.     Enable separate IPv4 and IPv6 traffic statistics for dual-stack portal users on the interface.

portal dual-stack traffic-separate enable

By default, separate IPv4 and IPv6 traffic statistics is disabled for dual-stack portal users on an interface. The device collects IPv4 and IPv6 traffic statistics collectively.

5.     Enable the dual IP feature to carry both IPv4 and IPv6 addresses for single-stack users in remote portal authentication.

portal dual-ip enable

By default, the dual IP feature is disabled.

6.     Return to system view.

quit

7.     Enable separate IPv4 and IPv6 traffic statistics in portal user offline logs.

portal user-log traffic-separate

By default, IPv4 and IPv6 traffic statistics of a portal user are collectively counted as IPv4 traffic statistics in portal user offline logs.

8.     Enable per-IP accounting for dual-stack portal users and portal users with multiple IPv6 addresses.

portal accounting-separate enable

By default, per-IP accounting is disabled for dual-stack portal users and portal users with multiple IPv6 addresses.

Configuring support of portal authentication for dual stack on a service template

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Enable the portal dual-stack feature on the service template.

portal dual-stack enable

By default, the portal dual-stack feature is disabled on a service template.

4.     Enable separate IPv4 and IPv6 traffic statistics for dual-stack portal users on the service template.

portal dual-stack traffic-separate enable

By default, separate IPv4 and IPv6 traffic statistics is disabled for dual-stack portal users on a service template. The device collects IPv4 and IPv6 traffic statistics collectively.

5.     Enable the dual IP feature to carry both IPv4 and IPv6 addresses for single-stack users in remote portal authentication.

portal dual-ip enable

By default, the dual IP feature is disabled.

6.     Return to system view.

quit

7.     Enable separate IPv4 and IPv6 traffic statistics in portal user offline logs.

portal user-log traffic-separate

By default, IPv4 and IPv6 traffic statistics of a portal user are collectively counted as IPv4 traffic statistics in portal user offline logs.

8.     Enable per-IP accounting for dual-stack portal users and portal users with multiple IPv6 addresses.

portal accounting-separate enable

By default, per-IP accounting is disabled for dual-stack portal users and portal users with multiple IPv6 addresses.

Setting the maximum number of portal users

About this task

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 an interface or service template.

Restrictions and guidelines for setting the maximum number of portal users

Make sure the maximum combined number of IPv4 and IPv6 portal users specified on all 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.

Setting the global maximum number of portal users

1.     Enter system view.

system-view

2.     Set the global maximum number of portal users.

portal max-user max-number

By default, no limit is set on the global number of portal users.

If you set the global maximum 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.

Setting the maximum number of portal users on an interface

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Set the maximum number of portal users.

portal { ipv4-max-user | ipv6-max-user } max-number

By default, no limit is set on the number of portal users on an interface.

If you set the maximum number smaller than the current number of portal users on an interface, this configuration still takes effect. The online users are not affected but the system forbids new portal users to log in from the interface.

Setting the maximum number of portal users on a service template

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Set the maximum number of portal users.

portal { ipv4-max-user | ipv6-max-user } max-number

By default, no limit is set on the number of portal users.

If you set the maximum number smaller than the current number of portal users on 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 service template.

Enabling strict-checking on portal authorization information

About this task

The strict checking feature allows a portal user to stay online only when the authorization information for the user is successfully deployed.

Enabling strict checking on portal authentication information on an interface

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Enable strict checking on portal authorization information.

portal authorization { acl | user-profile } strict-checking

 

CAUTION

CAUTION:

After this feature is enabled, a portal user will be logged out if the authorized ACL or user profile does not exist on the device or the device fails to deploy the authorized ACL or user profile.

You can enable strict checking on the authorized ACL, authorized user profile, or both. If you enable both ACL checking and user profile checking, the user will be logged out if either checking fails.

 

By default, strict checking on portal authorization information is disabled on an interface. Portal users stay online even when the authorized ACL or user profile does not exist or the device fails to deploy the authorized ACL or user profile.

Enabling strict checking on portal authorization information on a service template

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Enable strict checking on portal authorization information.

portal authorization { acl | user-profile } strict-checking

 

CAUTION

CAUTION:

After this feature is enabled, a portal user will be logged out if the authorized ACL or user profile does not exist on the device or the device fails to deploy the authorized ACL or user profile.

You can enable strict checking on the authorized ACL, authorized user profile, or both. If you enable both ACL checking and user profile checking, the user will be logged out if either checking fails.

 

By default, strict checking on portal authorization information is disabled on a service template. Portal users stay online even when the authorized ACL or user profile does not exist or the device fails to deploy the authorized ACL or user profile.

Allowing only users with DHCP-assigned IP addresses to pass portal authentication

About this task

This feature allows only users with DHCP-assigned IP addresses to pass portal authentication. Use this feature to ensure that only users with valid IP addresses can access the network.

Restrictions and guidelines

This feature takes effect only when the device acts as both the access device and the DHCP server.

Configuration of this feature does not affect the online portal users.

Allowing only users with DHCP-assigned IP addresses to pass portal authentication on an interface

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Allow only users with DHCP-assigned IP addresses to pass portal authentication.

portal [ ipv6 ] user-dhcp-only

 

CAUTION

CAUTION:

·     Users with static IP addresses cannot pass portal authentication to come online.

·     On an AC+fit AP network, this feature takes effect only when the AC acts as the DHCP server.

·     When this feature is configured, to ensure that IPv6 users can pass portal authentication, disable the temporary IPv6 address feature. Otherwise, IPv6 users will use temporary IPv6 addresses to access the IPv6 network and will fail portal authentication.

 

By default, both users with IP addresses obtained through DHCP and users with static IP addresses can pass authentication to come online.

Allowing only users with DHCP-assigned IP addresses to pass portal authentication on a service template

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Allow only users with DHCP-assigned IP addresses to pass portal authentication.

portal [ ipv6 ] user-dhcp-only

 

CAUTION

CAUTION:

·     Users with static IP addresses cannot pass portal authentication to come online.

·     On an AC+fit AP network, this feature takes effect only when the AC acts as the DHCP server.

·     When this feature is configured, to ensure that IPv6 users can pass portal authentication, disable the temporary IPv6 address feature. Otherwise, IPv6 users will use temporary IPv6 addresses to access the IPv6 network and will fail portal authentication.

 

By default, both users with IP addresses obtained through DHCP and users with static IP addresses can pass authentication to come online.

Enabling outgoing packets filtering

About this task

When you enable this feature on a portal-enabled interface or service template, the device permits the interface 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 interface or service template are dropped.

Enabling outgoing packets filtering on an interface

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Enable outgoing packets filtering on the interface.

portal [ ipv6 ] outbound-filter enable

By default, outgoing packets filtering is disabled on an interface. The interface can send any packets.

Enabling outgoing packets filtering on a service template

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Enable outgoing packets filtering on the service template.

portal [ ipv6 ] outbound-filter enable

By default, outgoing packets filtering is disabled on a service template. The service template can send any packets.

Enabling intra-VLAN roaming for portal users

About this task

If intra-VLAN roaming for portal users 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 intra-VLAN roaming for portal users 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:

1.     Logs out from the current port.

2.     Re-authenticates on the new Layer 2 port.

Restrictions and guidelines

You cannot enable intra-VLAN roaming when online portal users exist on the device.

For intra-VLAN roaming to take effect, you must disable the Rule ARP or ND entry feature by using the undo portal refresh { arp | nd } enable command.

Procedure

1.     Enter system view.

system-view

2.     Enable intra-VLAN roaming for portal users.

portal roaming enable

By default, intra-VLAN roaming is enabled for portal users.

Configuring inter-AC roaming for portal users

About this task

This feature allows portal users that have been authenticated on an AC to roam to another AC so as to access network resources without re-authentication. This feature must cooperate with the WLAN roaming center. For more information about the WLAN roaming center, see WLAN Roaming Configuration Guide.

Restrictions and guidelines

Do not configure both inter-AC roaming and MAC-based quick portal authentication.

This feature takes effect only on portal users that perform portal authentication on a webpage.

This feature must be used with the idle-cut or session timeout authorization attribute configured by using the authorization-attribute command.

Procedure

1.     Enter system view.

system-view

2.     Create a portal roaming center and enter its view.

portal roaming-center

3.     Specify the IPv4 address for communication with the WLAN roaming center.

ip ip-address

By default, the IPv4 address for communication with the WLAN roaming center is not specified.

4.     Specify the IPv6 address for communication with the WLAN roaming center.

ipv6 ipv6-address

By default, the IPv6 address for communication with the WLAN roaming center is not specified.

5.     Specify the UDP port number for communication with the WLAN roaming center.

port port-number

By default, the UDP port 1088 is used by the portal roaming center to communicate with the WLAN roaming center.

6.     (Optional.) Set the wait timer for responses from the WLAN roaming center.

response-timeout timeout

By default, the wait timer is 3 seconds.

7.     (Optional.) Set the maximum number of attempts for the portal roaming center to transmit a packet to the WLAN roaming center.

retry retries

By default, the maximum number of packet transmission attempts is 5.

8.     (Optional.) Enable the portal roaming center to deny user traffic.

user-traffic deny

By default, the portal roaming center does not deny user traffic.

9.     Enable the portal roaming center.

roaming-center enable

By default, the portal roaming center is disabled.

Configuring the portal fail-permit feature

About this task

You can configure the portal fail-permit feature on an interface or service template. When the access device detects that the portal authentication server or portal Web server is unreachable, it allows users to have network access without portal authentication.

If you enable fail-permit for both the portal authentication server and the portal Web servers, the device does the following:

·     Disables portal authentication when the portal authentication server is unreachable or all the portal Web servers are unreachable.

·     Resumes portal authentication when both the portal authentication and Web servers are reachable.

After portal authentication resumes, unauthenticated users must pass portal authentication to access the network. Users who have passed portal authentication before the fail-permit event can continue accessing the network.

Configuring portal fail-permit on an interface

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Enable portal fail-permit for a portal authentication server on the interface.

portal [ ipv6 ] fail-permit server server-name

By default, portal fail-permit is disabled for a portal authentication server on an interface.

4.     Enable portal fail-permit for portal Web servers on the interface.

portal [ ipv6 ] fail-permit web-server

By default, portal fail-permit is disabled for portal Web servers on an interface.

Configuring portal fail-permit on a service template

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Enable portal fail-permit for the portal Web servers on the service template.

portal [ ipv6 ] fail-permit web-server

By default, portal fail-permit is disabled for portal Web servers on a service template.

Configuring the NAS-Port-Type attribute

About this task

The NAS-Port-Type attribute carried in RADIUS requests represents the user's access interface type.

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.

When a portal user log in from an 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.

Configuring the NAS-Port-Type attribute on an interface

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Configure the NAS-Port-Type attribute on the interface.

portal nas-port-type { ethernet | wireless }

By default, the portal NAS-Port-Type attribute carried in RADIUS requests is the user's access interface type value obtained by the access device.

Configuring the NAS-Port-Type attribute on a service template

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Configure the NAS-Port-Type attribute on the interface.

portal nas-port-type { ethernet | wireless }

By default, the portal NAS-Port-Type attribute carried in RADIUS requests is the user's access interface type value obtained by the access device.

Enabling validity check on wireless clients

About this task

Enable this feature when portal authentication is enabled on a 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.

Restrictions and guidelines

You must enable this feature when portal authentication is enabled on a service template.

Procedure

1.     Enter system view.

system-view

2.     Enable validity check on wireless portal clients.

portal host-check enable

By default, validity check on wireless portal clients is enabled.

Configuring portal detection features

Configuring online detection of portal users

About this task

Use the online detection feature 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 detection. 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.

Restrictions and guidelines

ARP detection and ND detection apply only to direct portal authentication. ICMP detection applies to all portal authentication modes.

Procedure

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Configure online detection of portal users.

IPv4:

portal user-detect type { arp | icmp } [ retry retries ] [ interval interval ] [ idle time ]

IPv6:

portal ipv6 user-detect type { icmpv6 | nd } [ retry retries ] [ interval interval ] [ idle time ]

By default, online detection is disabled for portal users on an interface.

Configuring portal authentication server detection

About this task

During portal authentication, if the communication between the access device and portal authentication server is broken, new portal users are not able to log in. 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.

The portal authentication server detection feature enables the device to periodically detect 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.

Restrictions and guidelines

The portal authentication server detection feature takes effect only when the device has a portal-enabled interface.

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

Make sure the detection timeout configured on the device is greater than the server heartbeat interval configured on the portal authentication server.

Procedure

1.     Enter system view.

system-view

2.     Enter portal authentication server view.

portal server server-name

3.     Configure portal authentication server detection.

server-detect [ timeout timeout ] { log | trap } *

By default, portal authentication server detection is disabled.

Configuring portal Web server detection

About this task

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.

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

Restrictions and guidelines

The portal Web server detection feature takes effect only when the URL of the portal Web server is specified and the device has a portal-enabled interface.

On a wireless network, if the URL of the portal Web server uses the domain name, you must configure a DNS server to avoid portal Web server detection failure.

·     In centralized forwarding mode, configure the DNS server on the AC.

·     In local forwarding mode, configure the DNS server on the AP (by deploying a .map configuration file that contains the DNS server configuration to the AP).

Procedure

1.     Enter system view.

system-view

2.     Enter portal Web server view.

portal web-server server-name

3.     Configure portal Web server detection.

server-detect [ interval interval ] [ retry retries ] { log | trap } *

By default, portal Web server detection is disabled.

4.     Configure the URL and the type for portal Web server detection.

server-detect url string [ detect-type { http | tcp } ]

By default, the URL for portal Web server detection is the URL of the portal Web server. The type of portal Web server detection is TCP detection.

Enabling DHCP packet capture

About this task

This feature enables the AC to detect the online status of portal users by capturing DHCP packets of the portal users.

When this feature is enabled, the AC captures DHCP packets between a portal user and the DHCP server and obtains the IP address lease information of the user. The AC then detects the online status of the portal user as follows:

·     If the AC captures a DHCP lease renewal packet from the portal user before the lease expires, the AC determines that the portal user is online.

·     If no DHCP lease renewal packet is captured before the lease expires, the AC forcibly logs out the portal user.

For more information about DHCP packets, see DHCP configuration in Network Connectivity Configuration Guide.

The timeout time of the DHCP packet capture timer is the same as the IP address lease time in DHCP packets. This timer resets each time a DHCP packet is captured.

Procedure

1.     Enter system view.

system-view

2.     Enable DHCP packet capture to detect online status of portal users.

portal idle-cut dhcp-capture enable

By default, DHCP packet capture is disabled.

Configuring portal user synchronization

About this task

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.

Restrictions and guidelines

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.

Procedure

1.     Enter system view.

system-view

2.     Enter portal authentication server view.

portal server server-name

3.     Configure portal user synchronization.

user-sync timeout timeout

By default, portal user synchronization is disabled.

Configuring portal packet attributes

Configuring the BAS-IP or BAS-IPv6 attribute

About this task

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.

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.

Restrictions and guidelines

During a mandatory user logout process, the device sends portal notification packets to the portal authentication server. For the authentication or logout process to complete, make sure the BAS-IP or BAS-IPv6 attribute is the same as the device IP address specified on the portal authentication server.

You must configure the BAS-IP or BAS-IPv6 attribute on a portal authentication-enabled interface if the following conditions are met:

·     The portal authentication server is an H3C IMC server.

·     The portal device IP address specified on the portal authentication server is not the IP address of the portal packet output interface.

Configuring the BAS-IP or BAS-IPv6 attribute on an interface

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Configure the BAS-IP or BAS-IPv6 attribute.

IPv4:

portal bas-ip ipv4-address

By default, the BAS-IP attribute of an IPv4 portal reply packet is the source IPv4 address of the packet. The BAS-IP attribute of an IPv4 portal notification packet is the IPv4 address of the packet's output interface.

IPv6:

portal bas-ipv6 ipv6-address

By default, the BAS-IPv6 attribute of an IPv6 portal reply packet is the source IPv6 address of the packet. The BAS-IPv6 attribute of an IPv6 portal notification packet is the IPv6 address of the packet's output interface.

Configuring the BAS-IP attribute on a service template

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Configure the BAS-IP or BAS-IPv6 attribute.

IPv4:

portal bas-ip ipv4-address

By default, the BAS-IP attribute of an IPv4 portal reply packet is the source IPv4 address of the packet. The BAS-IP attribute of an IPv4 portal notification packet is the IPv4 address of the packet's output interface.

IPv6:

portal bas-ipv6 ipv6-address

By default, the BAS-IPv6 attribute of an IPv6 portal reply packet is the source IPv6 address of the packet. The BAS-IPv6 attribute of an IPv6 portal notification packet is the IPv6 address of the packet's output interface.

Specifying the device ID

About this task

The portal authentication server uses device IDs to identify the devices that send protocol packets to the portal server.

Restrictions and guidelines

Make sure the configured device ID is different than any other access devices communicating with the same portal authentication server.

Procedure

1.     Enter system view.

system-view

2.     Specify the device ID.

portal device-id device-id

By default, a device is not configured with a device ID.

Configuring attributes for RADIUS packets

Specifying a format for the NAS-Port-Id attribute

About this task

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 predefined formats (format 1, 2, 3, and 4). For more information about the formats, see portal commands in User Access and Authentication Command Reference.

Procedure

1.     Enter system view.

system-view

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.

Applying a NAS-ID profile to an interface

About this task

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.

Restrictions and guidelines

You can apply a NAS-ID profile to a portal-enabled interface. If no NAS-ID profile is specified on the interface or no matching NAS-ID is found in the specified profile, the device uses the device name as the interface NAS-ID.

Procedure

1.     Enter system view.

system-view

2.     Create a NAS-ID profile and enter NAS-ID profile view.

aaa nas-id profile profile-name

For more information about this command, see AAA commands in User Access and Authentication Command Reference.

3.     Configure a NAS ID and VLAN binding in the profile.

nas-id nas-identifier bind vlan vlan-id

For more information about this command, see AAA commands in User Access and Authentication Command Reference.

4.     Specify the NAS-ID profile on the interface.

a.     Return to system view.

quit

b.     Enter Layer 3 interface view.

interface interface-type interface-number

c.     Specify the NAS-ID profile on the interface.

portal nas-id-profile profile-name

Setting the user traffic backup threshold

About this task

The device backs up traffic for a user when the user's traffic reaches the user traffic backup threshold. A smaller threshold provides more accurate backup for user traffic. However, when a large number of users exist, a small threshold results in frequent user traffic backups, affecting the user online, offline, and accounting processes. Set a proper threshold to balance between service performance and traffic backup accuracy.

Procedure

1.     Enter system view.

system-view

2.     Set the user traffic backup threshold.

portal traffic-backup threshold value

By default, the user traffic backup threshold is 10 MB.

Configuring MAC-based quick portal authentication

Restrictions and guidelines for configuring MAC-based quick portal authentication

Do not configure both MAC-based quick portal authentication and inter-AC roaming.

Only direct authentication supports MAC-based quick portal authentication.

For MAC-based quick portal authentication to take effect on an interface configured with a portal preauthentication domain, set the free-traffic threshold to 0 bytes.

Configuring a remote MAC binding server

About this task

You can configure multiple MAC binding servers on the device.

Perform this task to configure MAC binding server parameters, such as the server's IP address port number, and the free-traffic threshold.

Procedure

1.     Enter system view.

system-view

2.     Create a MAC binding server and enter its view.

portal mac-trigger-server server-name

3.     Configure a MAC binding server.

¡     Specify the IP address of the MAC binding server.

IPv4:

ip ipv4-address [ key { cipher | simple } string ]

IPv6:

ipv6 ipv6-address [ key { cipher | simple } string ]

By default, no IP address is specified for a MAC binding server.

¡     (Optional.) Set the UDP port number on which the MAC binding server listens for MAC binding query packets.

port port-number

By default, the MAC binding server listens for MAC binding query packets on UDP port 50100.

¡     (Optional.) Set 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.

¡     (Optional.) Specify the type of the MAC binding server.

server-type { cmcc | imc }

By default, the type of a MAC binding server is IMC.

4.     (Optional.) Set the free-traffic threshold.

free-traffic threshold value

By default, the free-traffic threshold is 0 bytes.

5.     (Optional.) Set 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 not set.

6.     (Optional.) Specify the version of the portal protocol.

version version-number

By default, the version of the portal protocol is 1.

7.     (Optional.) Set 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.

8.     (Optional.) Set the aging time for MAC-trigger entries.

aging-time seconds

By default, the aging time for MAC-trigger entries is 300 seconds.

9.     (Optional.) Enable AAA failure unbinding.

aaa-fail nobinding enable

By default, AAA failure unbinding is disabled.

Configuring a local MAC binding server

About this task

To provide MAC-based quick portal authentication for local portal users, perform this task so that the access device acts as the local MAC binding server.

You can configure multiple local MAC binding servers on the device. For each server, you can configure parameters related to local MAC-based quick portal authentication.

Procedure

1.     Enter system view.

system-view

2.     Create a MAC binding server and enter its view.

portal mac-trigger-server server-name

3.     Enable local MAC-based quick portal authentication.

local-binding enable

By default, local MAC-based quick portal 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 minutes

By default, the aging time for local MAC-account binding entries is 720 minutes.

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

About this task

After a MAC binding server is specified on an interface, the device can implement MAC-based quick portal authentication for portal users on the interface.

Procedure

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Specify a MAC binding server on the interface.

portal [ ipv6 ] apply mac-trigger-server server-name

By default, no MAC binding server is specified on an interface.

Specifying a MAC binding server on a service template

About this task

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.

Procedure

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

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.

Configure cloud MAC-trigger authentication

About this task

This feature enables the cloud portal server to act as a MAC binding server to perform cloud MAC-trigger authentication on portal users.

Procedure

1.     Enter system view.

system-view

2.     Create a MAC binding server and enter its view.

portal mac-trigger-server server-name

3.     Enable cloud MAC-trigger authentication.

cloud-binding enable

By default, cloud MAC-trigger authentication is disabled.

4.     Specify the URL of the cloud portal authentication server.

cloud-server url url-string

By default, the cloud portal authentication server URL is not specified. The device uses the URL of the portal Web server as the URL of the cloud portal authentication server.

Disabling the Rule ARP or ND entry feature for portal clients

About this task

When the Rule ARP or ND entry feature is enabled for portal clients, ARP or ND entries for portal clients are Rule entries after the clients come online. The Rule entries will not age out and will be deleted immediately after the portal clients go offline. If a portal client goes offline and then tries to get online before the ARP or ND entry is relearned for the client, the client will fail the authentication. To avoid such authentication failure, disable this feature. Then, ARP or ND entries for portal clients are dynamic entries after the clients come online and are deleted only when they age out.

Restrictions and guidelines

Enabling or disabling of this feature does not affect existing Rule/dynamic ARP or ND entries.

Procedure

1.     Enter system view.

system-view

2.     Disable the Rule ARP or ND entry feature for portal clients.

undo portal refresh { arp | nd } enable

By default, the Rule ARP or ND entry feature is disabled for portal clients.

Disabling traffic accounting for portal users

About this task

The accounting server might perform time-based or traffic-based accounting, or it might not perform accounting.

If the accounting server does not perform traffic-based accounting, disable traffic accounting for portal users on the device. The device will provide quick accounting for portal users, and the traffic statistics will be imprecise.

If the accounting server performs traffic-based accounting, enable traffic accounting for portal users. The device will provide precise traffic statistics for portal users.

Procedure

1.     Enter system view.

system-view

2.     Disable traffic accounting for portal users.

portal traffic-accounting disable

By default, traffic accounting is enabled for portal users.

Logging out online portal users

About this task

This feature deletes users that have passed portal authentication and terminates ongoing portal authentications.

Restrictions and guidelines

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 disable portal authentication on the interface.

Procedure

1.     Enter system view.

system-view

2.     Log out online portal users.

IPv4:

portal delete-user { ipv4-address | all | auth-type { cloud | email | facebook | local | normal | qq | wechat } | interface interface-type interface-number | mac mac-address | username username }

IPv6:

portal delete-user { all | auth-type { cloud | email | facebook | local | normal | qq | wechat } | interface interface-type interface-number | ipv6 ipv6-address | mac mac-address | username username }

Automatically logging out wireless portal users

About this task

With this feature enabled, the device automatically logs out portal users after the wireless clients are disconnected from the network.

Procedure

1.     Enter system view.

system-view

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.

Kicking out a user after the user passes portal authentication

About this task

In some networks, for example, an Application Driven Campus (AD Campus) network, online users must be assigned authorization VLANs. Portal authentication does not support authorization VLAN assignment. You can perform this task on the device to kick out the portal users that come online by passing the MAC + portal transparent authentication. When such a user tries to come online again, the device performs MAC authentication for the user and assigns an authorization VLAN to the user.

Restrictions and guidelines

This feature takes effect only on portal users that come online after this feature is enabled. For existing portal users, you can log out the users manually.

You can configure a kick-out delay to ensure that the RADIUS server can finish recording a user and its client MAC address before the user is kicked out. If the RADIUS server cannot obtain the MAC address of the user, the user will fail the MAC authentication at the next login.

Procedure

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Kick out a user after the user passes portal authentication.

portal [ ipv6 ] authenticated-kick enable [ delay delay ]

By default, a user will not be kicked out after passing portal authentication.

Configuring Web redirect

About Web redirect

Web redirect is a simplified portal feature. With Web redirect, a user does not perform portal authentication but is directly redirected to the specified URL on the first Web access attempt in a 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.

Configuring destination-based portal redirection rules

About this task

The device uses destination-based portal redirection rules to perform URL redirection. If the Web request of a portal user matches the specified destination in a redirection rule, the device redirects the user to the URL specified in the redirection rule.

Restrictions and guidelines

If the Web request of a portal user matches a destination-based portal redirection rule and a URL redirection match rule (configured by using the if-match command), the redirection rule takes effect.

If you specify a host name or IP address in a destination-based portal redirection rule, do not specify a URL that includes the host name or IP address as the redirection URL in another rule. A violation will cause redirect loops.

The system supports a maximum of 10 destination-based portal redirection rules. For the same host or IP address, only one destination-based portal redirection rule is supported.

Procedure

1.     Enter system view.

system-view

2.     Configure a destination-based portal redirection rule.

portal redirect-rule destination { host { host-name | ip-address } | ipv6 ipv6-address } [ redirect-url url ]

By default, destination-based portal redirection rules with destination IP addresses 10.1.0.6 and 10.168.168.1 exist.

Configuring Web redirect on an interface

Restrictions and guidelines

The Web redirect feature takes effect only on HTTP packets that use the default port number 80.

To use the device URL as the Web redirect URL or allow users to successfully access the device URL, you must enable the HTTP service. To enable the HTTP service, use the ip http enable command.

When Web redirect and portal authentication are all enabled on an interface, the device redirects users on the interface as follows:

·     The device redirects the first HTTP request of a user to the specified URL. Then, the device redirects the next HTTP request of the user to the portal authentication page. After the user logs out, the user is redirected to the specified URL again at the first Web access.

·     After the specified redirect interval, a user is redirected to the specified URL regardless of whether the user is online or not. This process does not cause online users to be offline.

Procedure

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Configure Web redirect.

web-redirect [ ipv6 ] url url-string [ interval interval ]

By default, Web redirect is disabled.

Configuring Web redirect on a service template

Restrictions and guidelines

The Web redirect feature takes effect only on HTTP packets that use the default port number 80.

To use the device URL as the Web redirect URL or allow users to successfully access the device URL, you must enable the HTTP service. To enable the HTTP service, use the ip http enable command.

Do not enable both Web redirect and portal authentication on a service template.

On a wireless network, if the URL of the portal Web server uses the domain name, you must configure a DNS server to avoid portal Web redirect failure.

·     In centralized forwarding mode, configure the DNS server on the AC.

·     In local forwarding mode, configure the DNS server on the AP (by deploying a .map configuration file that contains the DNS server configuration to the AP).

Procedure

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

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.

Configuring portal safe-redirect

About this task

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

 

Procedure

1.     Enter system view.

system-view

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.

7.     (Optional.) Configure the default action for portal safe-redirect.

portal safe-redirect default-action { forbidden | permit }

By default, no default action is configured for portal safe-redirect.

8.     Configure a URL permitted by portal safe-redirect.

portal safe-redirect permit-url user-url-string

By default, no URLs permitted by portal safe-redirect are configured. The device redirects Web requests with any URLs.

Setting the maximum number of portal redirect sessions for a single user

About this task

If a user client is attacked by malicious software or viruses, it might initiate a large number of portal redirect sessions. You can perform this task to limit the number of portal redirect sessions that can be established for a user and limit the portal redirect session processing rate.

The maximum number applies to the HTTP redirect sessions and HTTPS redirect sessions separately. For example, assume you set the maximum number to 50. Then, the maximum number of portal redirect sessions that can be established per user and that can be processed per second are both 100 (50 for HTTP and 50 for HTTPS).

In wireless networks, the maximum number takes effect only in centralized forwarding mode.

Procedure

1.     Enter system view.

system-view

2.     Set the maximum number of portal redirect sessions for a single user.

portal redirect max-session per-user number

By default, no limit is set on the number of portal redirect sessions for a single user.

Setting the interval at which an AP reports traffic statistics to the AC

About this task

When the client traffic forwarding location is at APs, an AP reports traffic statistics to the AC at regular intervals.

Procedure

1.     Enter system view.

system-view

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

About this task

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.

Excluding an attribute from portal protocol packets for a portal authentication server

1.     Enter system view.

system-view

2.     Enter portal authentication server view.

portal server server-name

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.

Excluding an attribute from portal protocol packets for a MAC binding server

1.     Enter system view.

system-view

2.     Enter MAC binding server view.

portal mac-trigger-server server-name

3.     Exclude an attribute from portal protocol packets.

exclude-attribute attribute-number

By default, no attributes are excluded from portal protocol packets.

Configuring support of portal authentication for third-party authentication

About third-party authentication

The device supports using a third-party authentication server, such as QQ, email, WeChat, or Facebook authentication server as the portal authentication server to complete portal authentication. 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.

You need to add a third-party authentication button on the portal authentication page. A user clicks the button and is redirected to the third-party authentication page. The user then uses the third-party authentication account to perform portal authentication.

Restrictions and guidelines for third-party authentication

Only direct portal authentication that uses a local portal Web service supports third-party authentication.

Editing buttons and pages for third-party authentication

Restrictions and guidelines

No authentication button or authentication page is required for WeChat authentication.

Editing a third-party authentication button

To provide QQ, email, or Facebook authentication for portal users, you must add a QQ, email, or Facebook authentication button to the portal logon page.

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>

    <script type="text/javascript" language="javascript" src="pt_private.js"></script>

<script type="text/javascript">

      function setQQUrl(){

          document.getElementById("qqurl").href = pt_getQQSubmitUrl();

            }

</script>

    </head>

    <body>

    ... ...

<a href="javascript:void(null)" id="qqurl" onclick="setQQUrl()">QQ</a>

    ... ...

    </body>

</html>

No special requirements exist in the process of editing an email or Facebook authentication button.

Editing a third-party authentication page

You need to edit the email authentication page and the Facebook 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.

<form action= maillogin.html method = post >

<p>User name:<input type="text" name = "PtUser" style="width:160px;height:22px" maxlength=64>

<p>Password :<input type="password" name = "PtPwd" style="width:160px;height:22px" maxlength=32>

<p><input type=SUBMIT value="Logon" name = "PtButton" style="width:60px;" onclick="form.action=form.action+location.search;>

</form>

When you edit the Facebook authentication page, follow the rules in "Customizing authentication pages."

Configuring QQ authentication

About this task

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.

Prerequisites

To provide QQ authentication for portal users, you must go to 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.

Procedure

1.     Enter system view.

system-view

2.     Create a QQ authentication server and enter its view.

portal extend-auth-server qq

3.     (Optional.) Specify the URL of the QQ authentication server.

auth-url url-string

By default, the URL of a QQ authentication server is https://graph.qq.com.

4.     (Optional.) Specify the URL to which portal users are redirected after they pass QQ authentication.

redirect-url url-string

By default, portal users are redirected to URL http://oauthindev.h3c.com/portal/qqlogin.html after they pass QQ authentication.

5.     (Optional.) Specify the app ID for QQ authentication.

app-id app-id

By default, an app ID for QQ authentication exists.

6.     (Optional.) Specify the app key for QQ authentication.

app-key app-key

By default, an app key for QQ authentication exists.

Configuring email authentication

About this task

If a portal user chooses email authentication, the user can access the network after passing email authentication.

Procedure

1.     Enter system view.

system-view

2.     Create an email authentication server and enter its view.

portal extend-auth-server mail

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.

Configuring WeChat authentication

About this task

During WeChat authentication, the device first sends the credentials (app ID, app key, and shop ID) for WeChat authentication to the WeChat Official Account Platform for verification. After the credentials are verified, the device continues the portal authentication and allows the user to use the WiFi network after the authentication.

The subscribe-required feature requires users to follow the WeChat official account during WeChat authentication. If the users do not follow the WeChat official account, they fail WeChat authentication.

When subscribe-required feature is configured, the device sends the app ID and app secret to the WeChat Official Account Admin Platform to obtain the access token. Upon receiving authentication requests from portal users, the device sends the access token and the open ID in the authentication requests to the WeChat server to obtain user information. Based on the returned user information, the device determines whether the portal users have followed the WeChat official account.

Prerequisites

Before you configure WeChat authentication, you must go to the WeChat Official Account Admin Platform (https://mp.weixin.qq.com) to finish the following tasks:

1.     Apply a WeChat official account.

2.     Use the account to log in to the platform and enable the WeChat WiFi hotspot feature.

3.     Click the device management tab, add the device: select the shop where the device is deployed, select the portal device type, and enter the SSID of your WiFi network.

After the previous configurations, you will obtain the credentials (app ID, app key, and shop ID) for WeChat authentication.

To obtain the app secret for WeChat authentication, perform the following tasks:

1.     Use the WeChat official account to log in to the WeChat Official Account Admin Platform.

2.     From the navigation tree, select Developer Centers.

In the Configuration Items area, you can see the app secret for the WeChat Official account.

Procedure

1.     Enter system view.

system-view

2.     Create a WeChat authentication server and enter its view.

portal extend-auth-server wechat

3.     (Optional.) Specify the app ID for WeChat authentication.

app-id app-id

By default, no app ID is specified for WeChat authentication.

4.     (Optional.) Specify the app key for WeChat authentication.

app-key app-key

By default, no app key is specified for WeChat authentication.

5.     (Optional.) Specify the shop ID for WeChat authentication.

shop-id shop-id

By default, no app key is specified for WeChat authentication.

6.     (Optional.) Configure the subscribe-required feature.

a.     Enable the subscribe-required feature:

subscribe-required enable

By default, the subscribe-required feature is disabled.

This feature must be used with the portal temporary pass feature. As a best practice, set the temporary pass period to 600 seconds.

b.     Specify the app secret for WeChat authentication.

app-secret { cipher | simple } string

By default, no app secret is specified for WeChat authentication.

Configuring Facebook authentication

Prerequisites

To use Facebook authentication for portal users, you must register as a developer on the Facebook website to obtain an app ID and app key.

Procedure

1.     Enter system view.

system-view

2.     Create a Facebook authentication server and enter its view.

portal extend-auth-server facebook

3.     (Optional.) Specify the URL of the Facebook authentication server.

auth-url url-string

By default, the URL of Facebook authentication server is https://graph.facebook.com.

4.     (Optional.) Specify the URL to which portal users are redirected after they pass Facebook authentication.

redirect-url url-string

By default, portal users are redirected to URL http://oauthindev.h3c.com/portal/fblogin.html after they pass Facebook authentication.

5.     (Optional.) Specify the app ID for Facebook authentication.

app-id app-id

By default, no app ID is specified for Facebook authentication.

6.     (Optional.) Specify the app key for Facebook authentication.

app-key app-key

By default, no app key is specified for Facebook authentication.

Specifying an authentication domain for third-party authentication

About this task

Specify an authentication domain for third-party authentication on an interface or service template to apply the authentication, authorization, and accounting methods in the domain to portal users.

Restrictions and guidelines

Make sure the authentication, authorization, and accounting methods in the specified authentication domain are none.

Specifying an authentication domain for third-party authentication on an interface

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Specify an authentication domain for third-party authentication on the interface.

portal extend-auth domain domain-name

By default, no authentication domain is specified for third-party authentication on an interface.

Specifying an authentication domain for third-party authentication on a service template

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Specify an authentication domain for third-party authentication on the service template.

portal extend-auth domain domain-name

By default, no authentication domain is specified for third-party authentication on a service template.

Specifying the AC's interface for portal clients to access during third-party authentication

About this task

When client traffic is forwarded by APs and third-party portal authentication is used, the client does not know the IP address of the AC. For the client to access the AC successfully, specify an interface of the AC, so the client can obtain the AC's IP address and access the AC.

Procedure

1.     Enter system view.

system-view

2.     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 interface is specified for portal clients to access during third-party authentication.

Configuring portal temporary pass

About this task

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.

Restrictions and guidelines

This feature is appliable only to direct portal authentication.

If both portal safe-redirect and portal temporary pass match rules are configured, portal temporary pass match rules take precedence.

Configuring portal temporary pass on an interface

1.     Enter system view.

system-view

2.     Enter Layer 3 interface view.

interface interface-type interface-number

3.     Enable portal temporary pass and set the temporary pass period on the interface.

portal temp-pass [ period period-value ] enable

By default, portal temporary pass is disabled on an interface.

4.     Configure a match rule for portal temporary pass:

a.     Return to system view.

quit

b.     Enter portal Web server view.

portal web-server server-name

c.     Configure a match rule for portal temporary pass.

if-match { original-url url-string | user-agent user-agent } * temp-pass [ redirect-url url-string | original ]

By default, no match rules for portal temporary pass are configured.

Configuring portal temporary pass on a service template

1.     Enter system view.

system-view

2.     Enter service template view.

wlan service-template service-template-name

3.     Enable portal temporary pass and set the temporary pass period on the service template.

portal temp-pass [ period period-value ] enable

By default, portal temporary pass is disabled on a service template.

4.     Configure a match rule for portal temporary pass:

a.     Return to system view.

quit

b.     Enter portal Web server view.

portal web-server server-name

c.     Configure a match rule for portal temporary pass.

if-match { original-url url-string | user-agent user-agent } * temp-pass [ redirect-url url-string | original ]

By default, no match rules for portal temporary pass  are configured.

Setting the user synchronization interval for portal authentication using OAuth

About this task

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.

Procedure

1.     Enter system view.

system-view

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.

Configuring user synchronization for portal authentication using the WiFiDog protocol

About this task

Use this feature when users perform portal authentication using the WiFiDog protocol. This feature enables the device to periodically synchronize user information with the portal server to ensure user information consistency between the device and the portal server.

Restrictions and guidelines

For this feature to take effect, make sure the type of the portal Web server is WiFiDog before you perform this task. To specify the type of the portal Web server, use the server-type command.

Procedure

1.     Enter system view.

system-view

2.     Enable user information synchronization and set the synchronization interval for portal authentication using WiFiDog.

portal wifidog user-sync interval interval

By default, user information synchronization is disabled for portal authentication using WiFiDog.

Configuring portal authentication information report interval

About this task

After yo configure this feature, the device reports portal authentication failure and error information to the cloud platform. The first report is sent to the cloud server 30 seconds after the device is connected to the server. The subsequent reports are sent at regularly intervals as configured by this feature.

If you modify the report interval, the modified interval takes effect for the next report.

Procedure

1.     Enter system view.

system-view

2.     Configure the time interval at which portal authentication information is reported to the cloud platform.

portal cloud report interval minutes

By default, the portal authentication information is reported to the cloud platform at intervals of 5 minutes.

Enabling portal logging

About this task

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

Procedure

1.     Enter system view.

system-view

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 the portal authentication monitoring feature

About this task

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.

Procedure

1.     Enter system view.

system-view

2.     Enable portal user offline recording.

portal logout-record enable

By default, portal user offline recording is enabled.

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 supported on the device is 60000.

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 ]

5.     Enable portal authentication failure recording.

portal auth-fail-record enable

By default, portal authentication failure recording is enabled.

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 supported on the device is 60000.

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 ]

8.     Enable portal authentication error recording.

portal auth-error-record enable

By default, portal authentication error recording is enabled.

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 supported on the device is 60000.

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 ]

Logging out wireless portal users that switch SSIDs

About this task

When an authenticated user switches the SSID to access through another service template associated with the same VLAN with the original service template, the user fails portal authentication.

Use this feature to log out wireless portal users on the original service template when they switch SSIDs so that they can pass portal authentication on the new service template.

Procedure

1.     Enter system view.

system-view

2.     Enable the device to log out wireless portal users that switch SSIDs.

portal user-logoff ssid-switch enable

By default, the device does not log out wireless portal users that switch SSIDs and the users stay online.

Display and maintenance commands for portal

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

 

Task

Command

Display portal configuration and portal running state.

display portal { ap ap-name [ radio radio-id ] | interface interface-type interface-number }

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 packet statistics for portal captive-bypass.

display portal captive-bypass statistics

Display IP addresses corresponding to host names in destination-based portal-free rules.

display portal dns free-rule-host [ host-name ]

Display IP addresses resolved by host names in destination-based portal redirection rules.

display portal dns redirect-rule-host [ host-name ]

Display information about third-party authentication servers.

display portal extend-auth-server { all | facebook | mail | qq | wechat }

Display information about local MAC-account binding entries.

display portal local-binding mac-address { all | mac-address }

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 information about MAC-trigger authentication users (portal users that perform MAC-trigger authentication).

display portal mac-trigger user { all | ip ipv4-address | mac mac-address }

Display information about MAC binding servers.

display portal mac-trigger-server { all | name server-name }

Display packet statistics for portal authentication servers.

display portal packet statistics [ extend-auth-server { cloud | facebook | mail | qq | wechat } | mac-trigger-server server-name | server server-name ]

Display statistics for portal permit rules.

display portal permit-rule statistics

Display redirect session statistics for online portal users.

display portal redirect session [ ip ipv4-address | ipv6 ipv6-address ]

Display history records about portal redirect sessions.

display portal redirect session-record [ start-time start-date start-time ] [ end-time end-date end-time ]

Display summary statistics about portal redirect sessions.

display portal redirect session-statistics

Display portal redirect packet statistics.

display portal redirect statistics

Display packet statistics for the portal roaming center.

display portal roaming-center statistics packet

Display portal rules.

display portal rule { all | dynamic | static } { ap ap-name [ radio radio-id ] | interface interface-type interface-number }

Display packet statistics for portal safe-redirect

display portal safe-redirect statistics

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 | facebook | local | mac-trigger | normal | qq | wechat } | interface interface-type interface-number | ip ip-address | ipv6 ipv6-address | mac mac-address | username username } [ brief | verbose ]

Display the number of portal users.

display portal user count

Display DHCP lease information of IPv4 portal users.

display portal user dhcp-lease [ ipv4 ipv4-address ]

Display DHCPv6 lease information of IPv6 portal users.

display portal user dhcpv6-lease [ ipv6 ipv6-address ]

Display portal Web server information.

display portal web-server [ server-name ]

Display Web redirect rule information.

display web-redirect rule { ap ap-name [ radio radio-id ] | interface interface-type interface-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 packet statistics for portal captive-bypass.

reset portal captive-bypass statistics

Clear local MAC-account binding entries.

reset portal local-binding mac-address { mac-address | all }

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 packet statistics for portal authentication servers.

reset portal packet statistics [ extend-auth-server { cloud | facebook | mail | qq | wechat } | mac-trigger-server server-name | server server-name ]

Clear history records about portal redirect sessions.

reset portal redirect session-record

Clear summary statistics for portal redirect sessions.

reset portal redirect session-statistics

Clear portal redirect packet statistics.

reset portal redirect statistics

Clear packet statistics for the portal roaming center.

reset portal roaming-center statistics packet

Clear packet statistics for portal safe-redirect.

reset portal safe-redirect statistics

 

Portal configuration examples

Example: Configuring direct portal authentication on a VLAN interface

Network configuration

As shown in Figure 6, the AP directly forwards user traffic from the client. The client is assigned a public IP address either manually or through DHCP. An IMC server acts as both a portal authentication server and a portal Web server. A RADIUS server acts as the authentication/accounting server. In this example, the IMC server runs IMC PLAT 7.1 (E0303) and IMC UAM 7.1 (E0304).

Configure direct portal authentication, so the client can access only the portal Web server before passing the authentication and access other network resources after passing the authentication.

Figure 6 Network diagram

Configuring the RADIUS server

# Configure the RADIUS server correctly to provide authentication and accounting functions. (Details not shown.)

Configuring the portal server

1.     Configure the portal server:

a.     Log in to IMC and click the User tab.

b.     Select User Access Policy > Portal Service > Server from the navigation tree to open the portal server configuration page, as shown in Figure 7.

c.     Configure the portal server parameters as needed.

This example uses the default settings.

d.     Click OK.

Figure 7 Configuring a portal server

 

2.     Configure the IP address group:

a.     Select User Access Policy > Portal Service > IP Group from the navigation tree to open the portal IP address group configuration page.

b.     Click Add to open the page as shown in Figure 8.

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.

Figure 8 Adding an IP address group

 

3.     Add a portal device:

a.     Select User Access Policy > Portal Service > Device from the navigation tree to open the portal device configuration page.

b.     Click Add to open the page as shown in Figure 9.

c.     Enter device name NAS.

d.     Enter the IP address of the AC's interface that exchanges information with the portal server.

e.     Select whether to support sever 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 from the Access Method list.

h.     Click OK.

Figure 9 Adding a portal device

 

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

a.     As shown in Figure 10, click the Port Group Information Management coin  for device NAS to open the port group configuration page.

Figure 10 Device list

 

b.     Click Add to open the page as shown in Figure 11.

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 11 Adding a port group

 

Configuring the AC

1.     Assign IP addresses to interfaces and make sure the client, the AC, and the servers can reach each other. (Details not shown.)

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

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

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 direct portal authentication on VLAN-interface 100.

[AC] interface vlan-interface 100

[AC–Vlan-interface100] portal enable method direct

# Specify 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 the AC to the portal authentication server.

[AC–Vlan-interface100] portal bas-ip 2.2.2.1

[AC–Vlan-interface100] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.

[AC] display portal interface vlan-interface 100

 Portal information of Vlan-interface100

     NAS-ID profile: Not configured

     Authorization : Strict checking

     ACL           : Disabled

     User profile  : Disabled

     Dual stack    : Disabled

     Dual traffic-separate: Disabled

 IPv4:

     Portal status: Enabled

     Portal authentication method: Direct

     Portal Web server: newpt(active)

     Secondary portal Web server: Not configured

     Portal mac-trigger-server: Not configured

     Authentication domain: Not configured

     Extend-auth domain: Not configured

     User-dhcp-only: Disabled

     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

     Portal mac-trigger-server: Not configured

     Authentication domain: Not configured

     Extend-auth domain: Not configured

     User-dhcp-only: Disabled

     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 a Web browser. 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.

# After the user passes authentication, 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

    Session group profile: N/A

    ACL: N/A

Example: Configuring direct portal authentication on a service template

Network configuration

As shown in Figure 12, the AP directly forwards user traffic from the client. The client is assigned 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 direct portal authentication, so the client can access only the portal Web server before passing the authentication and access other network resources after passing the authentication.

Figure 12 Network diagram

Configuring the RADIUS server

# Configure the RADIUS server correctly to provide authentication and accounting functions. (Details not shown.)

Configuring the portal server

For more information about configuring the portal server, see "Example: Configuring direct portal authentication on a VLAN interface."

Configuring the AP

# Configure the AP to make sure the AP can communicate with the AC. (Details not shown.)

Configuring the AC

1.     Assign IP addresses to interfaces and make sure the client, the AC, and the servers can reach each other. (Details not shown.)

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

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

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

# Create the manual AP ap2, and specify the AP model and serial ID.

[AC] wlan ap ap2 model WA6320

[AC-wlan-ap-ap2] serial-id 219801A28N819CE0002T

# Create service template newst, set the SSID to portal 1.

[AC] wlan service-template newst

[AC–wlan-st-newst] ssid portal_1

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

     Dual stack    : Disabled

     Dual traffic-separate: Disabled

 IPv4:

     Portal status: Enabled

     Portal authentication method: Direct

     Portal Web server: newpt(active)

     Secondary portal Web server: Not configured

     Portal mac-trigger-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

     Portal mac-trigger-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

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

# After the user passes authentication, 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

    Session group profile: N/A

    ACL number: N/A

Example: Configuring extended direct portal authentication

Network configuration

As shown in Figure 13, the client is connected to the AC through the AP. The client is assigned 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 direct 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 other network resources.

Figure 13 Network diagram

Configuring the RADIUS server and the portal server

# Configure the RADIUS server and the portal server correctly to provide authentication and accounting functions. (Details not shown.)

Configuring the AC

1.     Assign IP addresses to interfaces and make sure the client, the AC, and the servers can reach each other. (Details not shown.)

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

# Exclude the ISP domain name from the username sent to the RADIUS server.

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

# Specify a security policy server with IP address 192.168.0.113.

[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.112 and shared key 12345 in plaintext form.

[AC] radius session-control client ip 192.168.0.112 key simple 12345

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

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

 

5.     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 direct portal authentication on VLAN-interface 100.

[AC] interface vlan-interface 100

[AC–Vlan-interface100] portal enable method direct

# Specify portal Web server newpt on VLAN-interface 100.

[AC–Vlan-interface100] portal apply web-server newpt

# Configure the BAS-IP as 2.2.2.1 for portal packets sent from VLAN-interface 100 to the portal authentication server.

[AC–Vlan-interface100] portal bas-ip 2.2.2.1

[AC–Vlan-interface100] quit

Verifying the configuration

# Verify that the portal configuration has taken effect.

[AC] display portal interface vlan-interface 100

 Portal information of Vlan-interface100

     NAS-ID profile: Not configured

     Authorization : Strict checking

     ACL           : Disabled

     User profile  : Disabled

     Dual stack    : Disabled

     Dual traffic-separate: Disabled

 IPv4:

     Portal status: Enabled

     Portal authentication method: Direct

     Portal Web server: newpt(active)

     Secondary portal Web server: Not configured

     Portal mac-trigger-server: Not configured

     Authentication domain: Not configured

     Extend-auth domain: Not configured

     User-dhcp-only: Disabled

     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

     Portal mac-trigger-server: Not configured

     Authentication domain: Not configured

     Extend-auth domain: Not configured

     User-dhcp-only: Disabled

     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 network resources permitted by ACL 3001 after passing both identity authentication and security check.

# After the user passes identity authentication and security check, 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            --     Vlan-interface100

  Authorization information:

    DHCP IP pool: N/A

    User profile: N/A

    Session group profile: N/A

    ACL: 3001

Example: Configuring portal server detection

Network configuration

As shown in Figure 14, the client is connected to the AC through the AP. The client is assigned a public IP address either manually or through DHCP. An IMC server acts as both a portal authentication server and a portal Web server. A RADIUS server acts as the authentication/accounting server. In this example, the IMC server runs IMC PLAT 7.1 (E0303) and IMC UAM 7.1 (E0304).

·     Configure direct portal authentication on the AC, so the client can access only the portal server before passing the authentication and access other network 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 14 Network diagram

Configuring the RADIUS server

# Configure the RADIUS server correctly to provide authentication and accounting functions. (Details not shown.)

Configuring the portal server

1.     Configure the portal server:

a.     Log in to IMC and click the User tab.

b.     Select User Access Policy > Portal Service > Server from the navigation tree to open the portal server configuration page, as shown in Figure 15.

c.     Configure the portal server parameters as needed.

This example uses the default settings.

d.     Click OK.

Figure 15 Portal authentication server configuration

 

2.     Configure the IP address group:

a.     Select User Access Policy > Portal Service > IP Group from the navigation tree to open the portal IP address group configuration page.

b.     Click Add to open the page as shown in Figure 16.

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 Normal from the Action list.

g.     Click OK.

Figure 16 Adding an IP address group

 

3.     Add a portal device:

a.     Select User Access Policy > Portal Service > Device from the navigation tree to open the portal device configuration page.

b.     Click Add to open the page as shown in Figure 17.

c.     Enter device name NAS.

d.     Enter the IP address of the AC's interface connected to the host.

e.     Select whether to support server heartbeat and user heartbeat functions.

In this example, select Yes 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 Direclty Connected from the Access Method list.

h.     Click OK.

Figure 17 Adding a portal device

 

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

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

Figure 18 Device list

 

b.     Click Add to open the page as shown in Figure 19.

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 19 Adding a port group

 

Configuring the AC

1.     Assign IP addresses to interfaces and make sure the client, the AC, and the servers can reach each other. (Details not shown.)

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

3.     Configure an authentication domain:

# Create an ISP domain named dm1 and enter its view.

[AC] radius session-control enable

# 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

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

# 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

[AC-portal-server-newpt] quit

 

 

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 direct portal authentication on VLAN-interface 100.

[AC] interface vlan-interface 100

[AC–Vlan-interface100] portal enable method direct

# Enable portal fail-permit for portal authentication server newpt.

[AC–Vlan-interface100] portal fail-permit server newpt

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

# 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 host can access the external network without authentication.

Example: Configuring direct portal authentication using a local portal Web service

Network configuration

As shown in Figure 20, the client is connected to the AC through the AP. The client is assigned 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 direct portal authentication on the AC. Before a user passes portal authentication, the user can access only the portal Web server. After passing portal authentication, the user can access other network resources.

Figure 20 Network diagram

Prerequisites

Customize the authentication pages, compress them to a file, and upload the file to the root directory of the storage medium of the AC.

Configuring the RADIUS server

# Configure the RADIUS server correctly to provide authentication and accounting functions. (Details not shown.)

Configuring the AC

1.     Assign IP addresses to interfaces and make sure the client, the AC, and the servers can reach each other. (Details not shown.)

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

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

4.     Configure portal authentication:

# Configure a portal Web server.

[AC] portal web-server newpt

[AC-portal-websvr-newpt] url http://2.2.2.1:2331/portal

[AC-portal-websvr-newpt] quit

# Enable direct portal authentication on VLAN-interface 100.

[AC] interface vlan-interface 100

[AC–Vlan-interface100] portal enable method direct

# Specify portal Web server newpt on VLAN-interface 100.

[AC–Vlan-interface100] portal apply web-server newpt

[AC–Vlan-interface100] quit

# Create an HTTP-based local portal Web service and enter its view.

[AC] portal local-web-server http

# Specify file defaultfile.zip as the default authentication page file for the local portal Web service. (Make sure the file exist under the root directory of the AC.)

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

# Set the HTTP listening port number to 2331 for the local portal Web service.

[AC–portal-local-websvr-http] tcp-port 2331

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

Verifying the configuration

# Verify that the portal configuration has taken effect.

[AC] display portal interface vlan-interface 100

 Portal information of Vlan-interface 100

     Authorization                   Strict checking

     ACL                             Disabled

     User profile                    Disabled

     Dual stack    : Disabled

     Dual traffic-separate: Disabled

 IPv4:

     Portal status: Enabled

     Portal authentication method: Direct

     Portal Web server: newpt(active)

     Secondary portal Web server: Not configured

     Portal mac-trigger-server: Not configured

     Authentication domain: Not configured

     Extend-auth domain: Not configured

     User-dhcp-only: Disabled

     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

     Portal mac-trigger-server: Not configured

     Authentication domain: Not configured

     Extend-auth domain: Not configured

     User-dhcp-only: Disabled

     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 a 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 other network resources.

# After the user passes authentication, 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

    Session group profile: N/A

    ACL: N/A

Example: Configuring remote MAC-based quick portal authentication

Network configuration

As shown in Figure 21, the client accesses the WLAN through the AP. The client is assigned a public IP address either manually or through DHCP. An IMC 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. In this example, the IMC server runs IMC PLAT 7.1 (E0303) and IMC UAM 7.1 (E0303).

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 21 Network diagram

Configuring the RADIUS server

# Configure the RADIUS server correctly to provide authentication and accounting functions. (Details not shown.)

Configuring the portal server

1.     Configure the portal server:

a.     Log in to IMC and click the User tab.

b.     Select User Access Policy > Portal Service > Server from the navigation tree to open the portal server configuration page, as shown in Figure 22.

c.     Configure the portal server parameters as needed.

This example uses the default values.

d.     Click OK.

Figure 22 Portal authentication server configuration

 

2.     Configure the IP address group:

a.     Select User Access Policy > Portal Service > IP Group from the navigation tree to open the portal IP address group configuration page.

b.     Click Add to open the page as shown in Figure 23.

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 23 Adding an IP address group

 

3.     Add a portal device:

a.     Select User Access Policy > Portal Service > Device from the navigation tree to open the portal device configuration page.

b.     Click Add to open the page as shown in Figure 24.

c.     Enter the device name.

d.     Enter the IP address of the AC's interface connected to the client.

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 from the Access Method list.

h.     Click OK.

Figure 24 Adding a portal device

 

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

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

Figure 25 Device list

 

b.     Click Add to open the page as shown in Figure 26.

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 26 Adding a port group

 

Configuring the MAC binding server

1.     Add an access policy:

a.     Select User Access Policy > Access Policy from the navigation tree to open the access policy page.

b.     Click Add to open the page as shown in Figure 27.

c.     Enter the access policy name.

d.     Select a service group.

e.     Use the default settings for other parameters.

f.     Click OK.

Figure 27 Adding an access policy

 

2.     Add an access service:

a.     Select User Access Policy > Access Service from the navigation tree to open the access service page.

b.     Click Add to open the page as shown in Figure 28.

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 28 Adding an access service

 

3.     Add an access user:

a.     Select Access User > All Access Users from the navigation tree to open the access user page.

b.     Click Add to open the page as shown in Figure 29.

c.     Select an access user.

d.     Set the password.

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

f.     Click OK.

Figure 29 Adding an access user

 

4.     Configure system parameters:

a.     Select User Access Policy > Service Parameters > System Settings from the navigation tree to open the system settings page.

b.     Click the Configure icon 2013-07-29_144255.png for User Endpoint Settings to open the page as shown in Figure 30.

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

 

e.     Click the Configure icon 2013-07-29_144255.png for Endpoint Aging Time to open the page as shown in Figure 31.

f.     Set the endpoint aging time as needed.

This example uses the default value.

Figure 31 Setting the endpoint aging time

 

Configuring the AC

1.     Assign IP addresses to interfaces and make sure the client, the AC, and the servers can reach each other. (Details not shown.)

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

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

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 validity check on the wireless client.

[AC] portal host-check enable

# Create a service template named 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 direct authentication on service template st1.

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

# Specify the portal Web server newpt on service template st1.

[AC–wlan-st-st1] portal apply web-server newpt

# Configure the BAS-IP as 2.2.2.1 for portal packets sent from service template st1 to the portal authentication server.

[AC-wlan-st-st1] portal bas-ip 2.2.2.1

[AC-wlan-st-st1] quit

5.     Configure MAC-based quick portal authentication:

# Create a MAC binding server named 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 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 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 a Web browser. 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

    Session group profile: N/A

    ACL number/name: N/A

    CAR: N/A

Example: Configuring local MAC-based quick portal authentication

Network configuration

As shown in Figure 32, 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 minutes after the user passes portal authentication for the first time.

Figure 32 Network diagram

Procedure

1.     Assign IP addresses to interfaces and make sure the client, the AC, and the servers can reach each other. (Details not shown.)

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

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

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

[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 an HTTP-based local portal Web service and enter its view.

[AC] portal local-web-server http

# Specify file defaultfile.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 defaultfile.zip

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

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

  aaa-fail nobinding         : Disabled

  Excluded attribute list    : Not configured

  Cloud-binding              : Disabled

  Cloud-server URL           : Not configured

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.

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 information about local MAC-account binding entries.

[AC] display portal local-binding mac-address all

Total mac-address number:   1

  Mac-address           User-name

  0800-2700-b43a         client1

# Display information about portal users on VLAN-interface 100.

[AC] display portal user interface vlan-interface100

Total portal users: 1

Username: client1

  Portal server: N/A

  State: Online

  VPN instance: N/A

  MAC                IP                 VLAN   Interface

  0800-2700-b43a     192.168.0.56       100    WLAN-BSS1/0/1

  Authorization information:

    DHCP IP pool: N/A

    User profile: N/A

    Session group profile: N/A

    ACL number/name: N/A

    CAR: N/A

Example: Configuring cloud MAC-trigger authentication

Network configuration

As shown in Figure 33:

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

·     The cloud server acts as the portal authentication server, the portal Web server, and the MAC binding server.

Configure cloud MAC-trigger authentication to meet the following requirements:

·     A user can access only the portal Web server before passing portal authentication.

·     A user can access the network resources after passing portal authentication. The user can pass portal authentication without entering a username or password when the user tries to come online again.

Figure 33 Network diagram

Configuring the cloud server

# On the Oasis platform, enable Auth free for reconnect on the authentication template for the AC. (Details not shown.)

Configuring the AC

1.     Assign IP addresses to interfaces and make sure the client, AC, and servers can reach each other. (Details not shown.)

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

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

# Enable DNS proxy.

[AC] dns proxy enable

# 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.100.0/24.

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

# Exclude IP address 192.168.100.1 from dynamic allocation.

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

# Specify 192.168.100.1 as the gateway address.

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

# Specify 192.168.100.1 as the DNS server address.

[AC-dhcp-pool-client] dns-list 192.168.100.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

3.     Configure an ISP domain:

# Create an ISP domain named cloud.

[AC] domain cloud

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

[AC-isp-cloud] authentication portal none

[AC-isp-cloud] authorization portal none

[AC-isp-cloud] accounting portal none

[AC-isp-cloud] quit

4.     Configure cloud MAC-trigger authentication:

# Create a portal Web server named wbs.

[AC] portal web-server wbs

# Specify http://oasisauth.h3c.com as the URL of portal Web server wbs.

[AC-portal-websvr-wbs] url http://oasisauth.h3c.com

# Specify the type of the portal Web server as oauth.

[AC-portal-websvr-wbs] server-type oauth

# Enable the portal captive-bypass feature.

[AC-portal-websvr-wbs] captive-bypass enable

# Configure a temporary pass rule to temporarily allow user packets that access URL http://oasisauth.h3c.com to pass.

[AC-portal-websvr-wbs] if-match original-url http://oasisauth.h3c.com temp-pass

[AC-portal-websvr-wbs] quit

# Enable cloud MAC-trigger authentication.

[AC] portal mac-trigger-server abc

[AC-portal-extend-auth-server-abc] cloud-binding enable

# Specify http://oasisauth.h3c.com as the URL of the cloud portal authentication server.

[AC-portal-extend-auth-server-abc] cloud-server url http://oasisauth.h3c.com

[AC-portal-extend-auth-server-abc] 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 cloud.

[AC-wlan-st-st1] ssid cloud

# Enable direct portal authentication on service template st1.

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

# Specify ISP domain cloud as the portal authentication domain.

[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

# Specify MAC binding server abc on service template st1.

[AC-wlan-st-st1] portal apply mac-trigger-server abc

# Enable portal temporary pass and set the temporary pass period to 60 seconds.

[AC-wlan-st-st1] portal temp-pass period 60 enable

# Enable service template st1.

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

[AC-wlan-st-st1] quit

# Create AP lvzhou-ap with model WA6320, and set its serial ID to 219801A28N819CE0002T.

[AC] wlan ap lvzhou-ap model WA6320

[AC-wlan-ap-lvzhou-ap] serial-id 219801A28N819CE0002T

# 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

# 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 packet statistics for the cloud portal authentication server.

[AC] display portal packet statistics extend-auth-server cloud

Extend-auth server : cloud

  Pkt-Type           Success      Error      Timeout      Conn-failure

  REQ_ACCESSTOKEN    1            0          0            0

  REQ_USERINFO       1            0          0            0

  RESP_ACCESSTOKEN   1            0          0            0

  RESP_USERINFO      1            0          0            0

  POST_ONLINEDATA    10           0          0            0

  RESP_ONLINEDATA    10           0          0            0

  POST_OFFLINEUSER   1            0          0            0

  REPORT_ONLINEUSER  2            0          0            0

  REQ_CLOUDBIND      2            0          0            0

  ESP_CLOUDBIND      2            0          0            0

  REQ_BINDUSERINFO   1            0          0            0

  RESP_BINDUSERINFO  1            0          0            0

  AUTHENTICATION     2            0          0            0

Before passing portal authentication, a user can access only the portal authentication page http://oasisauth.h3c.com. All Web requests from the user will be redirected to the portal authentication page. After passing portal authentication, the user can access other network resources.

The user needs to enter the username and password for the first authentication. If the user goes offline and then tries to come online, the user can directly access the network resources without entering the username and password.

# Display information about all portal users.

[AC] display portal user all

Total portal users: 1

Username: client1

  AP name: lvzhou-ap

  Radio ID: 2

  SSID: WXauth

  Portal server: N/A

  State: Online

  VPN instance: N/A

  MAC                IP                 VLAN   Interface

  582a-f776-8050     192.168.100.3      100    WLAN-BSS2/0/5

  Authorization information:

    DHCP IP pool: N/A

    User profile: N/A

    Session group profile: N/A

    ACL number/name: N/A

    Inbound CAR: N/A

    Outbound CAR: N/A

Example: Configuring portal support for QQ authentication

Network configuration

As shown in Figure 34, 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 34 Network diagram

Prerequisites

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.

Procedure

1.     Assign IP addresses to interfaces and make sure the client, the AC, and the QQ server can reach each other. (Details not shown.)

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

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

4.     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 direct 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 WA6320, and set its serial ID to 219801A28N819CE0002T.

[AC] wlan ap ap1 model WA6320

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

# 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 an HTTP-based local portal Web service and enter its view.

[AC] portal local-web-server http

# Specify the file defaultfile.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 defaultfile.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://oauthindev.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

    Session group profile: N/A

    ACL number/name: N/A

    CAR: N/A

Example: Configuring portal support for email authentication

Network configuration

As shown in Figure 35, 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 35 Network diagram

Prerequisites

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.

Procedure

1.     Assign IP addresses to interfaces and make sure the client, the AC, and the mail server can reach each other. (Details not shown.)

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

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

4.     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 direct 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 WA6320, and set its serial ID to 219801A28N819CE0002T.

[AC] wlan ap ap1 model WA6320

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

# 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 an HTTPS-based local portal Web service and enter its view.

[AC] portal local-web-server https

# Specify the file defaultfile.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 defaultfile.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

    Session group profile: N/A

    ACL number/name: N/A

    CAR: N/A

Example: Configuring portal inter-AC roaming

Network configuration

As shown in Figure 36, configure AC 1 as the WLAN roaming center and AC 2 and AC 3 as portal roaming centers to enable the client to roam from AC 2 to AC 3 without being authenticated.

Figure 36 Network diagram

Configuring AC 1

# Create a WLAN roaming center and enter its view.

<AC1> system-view

[AC1] wlan roaming-center

# Specify the port used by the WLAN roaming center as port 40000.

[AC1-wlan-roaming-center] port 40000

# Enable the WLAN roaming center.

[AC1-wlan-roaming-center] roaming-center enable

[AC1-wlan-roaming-center] quit

Configuring AC 2

1.     Assign IP addresses to interfaces and make sure the client, server, and AC can reach each other. (Details not shown.)

2.     Configure a RADIUS scheme:

# Create RADIUS scheme rs1 and enter its view.

<AC2> system-view

[AC2] radius scheme rs1

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

[AC2-radius-rs1] primary authentication 192.168.0.112

[AC2-radius-rs1] primary accounting 192.168.0.112

[AC2-radius-rs1] key authentication simple radius

[AC2-radius-rs1] key accounting simple radius

# Exclude the ISP domain name from the username sent to the RADIUS server.

[AC2-radius-rs1] user-name-format without-domain

[AC2-radius-rs1] quit

# Enable RADIUS session control.

[AC2] radius session-control enable

3.     Configure an authentication domain:

# Create an ISP domain named dm1 and enter its view.

[AC2] domain dm1

# Configure AAA methods for the ISP domain.

[AC2-isp-dm1] authentication portal radius-scheme rs1

[AC2-isp-dm1] authorization portal radius-scheme rs1

[AC2-isp-dm1] accounting portal radius-scheme rs1

[AC2-isp-dm1] quit

# Configure domain dm1 as the default ISP domain. If a user uses a username without the ISP domain name at login, the authentication and accounting methods of the default domain are used for the user.

[AC2] domain default enable dm1

4.     Configure portal authentication:

# Configure a portal authentication server.

[AC2] portal server newpt

[AC2-portal-server-newpt] ip 192.168.0.111 key simple portal

[AC2-portal-server-newpt] port 50100

[AC2-portal-server-newpt] quit

# Configure a portal Web server.

[AC2] portal web-server newpt

[AC2-portal-websvr-newpt] url http://192.168.0.111:8080/portal

[AC2-portal-websvr-newpt] quit

# Create AP ap2 and specify the AP model and serial ID.

[AC2] wlan ap ap2 model WA6320

[AC2-wlan-ap-ap2] serial-id 219801A28N819CE0002T

[AC2-wlan-ap-ap2] quit

# Create service template newst and set the SSID to portal_1.

[AC2] wlan service-template newst

[AC2–wlan-st-newst] ssid portal_1

# Enable direct portal authentication.

[AC2–wlan-st-newst] portal enable method direct

# Apply portal Web server newpt.

[AC2–wlan-st-newst] portal apply web-server newpt

# Configure the BAS-IP as 192.168.0.110 for portal packets sent to the portal authentication server.

[AC2–wlan-st-newst] portal bas-ip 192.168.0.110

# Configure APs to forward client data traffic.

[AC2–wlan-st-newst] client forwarding-location ap

# Enable the service template.

[AC2–wlan-st-newst] service-template enable

[AC2–wlan-st-newst] quit

# Specify the working channel of radio 2 on AP ap2 as 11.

[AC2] wlan ap ap2

[AC2-wlan-ap-ap2] radio 2

[AC2-wlan-ap-ap2-radio-2] channel 11

# Enable radio 2. Apply service template newst and bind VLAN 2 to the radio.

[AC2-wlan-ap-ap2-radio-2] radio enable

[AC2-wlan-ap-ap2-radio-2] service-template newst vlan 2

[AC2-wlan-ap-ap2-radio-2] quit

[AC2-wlan-ap-ap2] quit

5.     Configure the portal roaming center:

# Enter portal roaming center view.

[AC2] portal roaming-center

# Specify the IP address of the WLAN roaming center as 192.168.1.1.

[AC2-portal-roaming-center] ip 192.168.1.1

# Configure the portal roaming center to use port 40000 to communicate with the WLAN roaming center.

[AC2-portal-roaming-center] port 40000

# Set the wait timer for user offline notification responses to 5 seconds.

[AC2-portal-roaming-center] response-timeout 5

# Set the maximum transmission attempts for packets sent to the WLAN roaming center to 3.

[AC2-portal-roaming-center] retry 3

# Enable the portal roaming center.

[AC2-portal-roaming-center] roaming-center enable

[AC2-portal-roaming-center] quit

Configuring AC 3

# Configure AC 3 in the same way AC 2 is configured. (Details not shown.)

Configuring the AAA server

1.     Configure the RADIUS server correctly for the server to provide authentication and accounting functions. (Details not shown.)

2.     Configure the portal authentication server:

 

 

NOTE:

In this example, the portal server runs on IMC PLAT 7.1(E0303) and IMC EIA 7.1(E0304).

 

a.     Log in to IMC and click the User tab.

b.     Select User Access Policy > Portal Service > Server from the navigation tree, as shown in Figure 37.

c.     Configure the portal server parameters as needed.

This example uses the default settings.

d.     Click OK.

Figure 37 Configuring the portal server

 

3.     Configure the IP address group:

a.     Select User Access Policy > Portal Service > IP Group from the navigation tree.

b.     Click Add.

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 Normal from the Action list.

g.     Click OK.

Figure 38 Adding an IP address group

 

4.     Add a portal device:

a.     Select User Access Policy > Portal Service > Device from the navigation tree.

b.     Click Add.

c.     Enter the device name NAS.

d.     Enter the IP address of the interface that connects the router to the host.

e.     Set whether to support the portal server heartbeat and user heartbeat functions.

In this example, No is selected for both Support Server Heartbeat and Support User Heartbeat.

f.     Enter the key, which must be the same as that configured on the router.

g.     Select Directly Connected as the Access Method.

h.     Click OK.

Figure 39 Adding a portal device

 

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

a.     As shown in Figure 40, click the Port Group Information Management icon for device NAS.

b.     Click Add.

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

 

Figure 41 Adding a port group

 

6.     Select User Access Policy > Service Parameters > Validate System Configuration from the navigation tree to make the configurations take effect.

Verifying the configuration

# Display client information on the WLAN roaming center.

[AC1] display wlan roaming-center user all

Total user: 1

MAC address               IP address

000d-88f8-0eac            122.122.111.100

# Display detailed client roaming information on the WLAN roaming center.

[AC1] display wlan roaming-center user all verbose

MAC address: 000d-88f8-0eac

  IP address: 122.122.111.100

  Username: 1

  Authorization information:

User profile: abc

ACL number/name: N/A

Inbound CAR: N/A

Outbound CAR: N/A

    Session Timeout period: N/A

    Idle cut: N/A

  Roaming information:

    Online BAS IP: 192.168.0.10

    Online time: 12:01:12 01/02 2018 UTC

    Roaming count: 3

      BAS-IP                          Roam-in time

      192.168.0.11                    12:20:12 01/02 2018 UTC

      192.168.0.10                    12:18:12 01/02 2018 UTC

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 this command in portal authentication server view 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.