Table of Contents

Chapter 1 Portal Configuration. 1-1

1.1 Portal Overview. 1-1

1.1.1 Introduction to Portal 1-1

1.1.2 Portal System Components. 1-1

1.1.3 Portal Authentication Mode. 1-3

1.1.4 Portal Authentication Process. 1-4

1.2 Portal Configuration Task List 1-7

1.3 Basic Portal Configuration. 1-7

1.3.1 Configuration prerequisites. 1-7

1.3.2 Configuration Procedure. 1-7

1.4 Configuring an Authentication-Free Rule. 1-8

1.5 Configuring an Authentication Subnet 1-9

1.6 Forcing a User to Log Out 1-9

1.7 Displaying and Maintaining Portal 1-10

1.8 Portal Configuration Example. 1-11

1.8.1 Layer 3 Portal Direct Authentication Configuration Example. 1-11

1.9 Troubleshooting Portal 1-13

1.9.1 Inconsistent Keys on the Access Device and the Portal Server 1-13

1.9.2 Incorrect Server Port Number on the Access Device. 1-13

 

Chapter 1  Portal Configuration

When configuring portal, go to these sections for information you are interested in:

l           Portal Overview

l           Portal Configuration Task List

l           Displaying and Maintaining Portal

l           Portal Configuration Example

l           Troubleshooting Portal

1.1  Portal Overview

1.1.1  Introduction to Portal

Portal authentication, as its name implies, helps control access to the Internet. Portal authentication is also called web authentication and a website implementing portal authentication is called a portal website.

With portal authentication, an access device forces any user to log into the portal website at first. A user can access the free services provided on the portal website; but to access the Internet, the user must pass portal authentication on the portal website.

A user can access a known portal website and enter username and password for authentication. This authentication mode is called active authentication. There is still another authentication mode, namely forced authentication, in which the access device forces a user trying to access the Internet through HTTP to log in to a portal website for authentication.

The portal feature provides the flexibility for Internet service providers (ISPs) to manage services. A portal website can, for example, present advertisements, and deliver community services and personalized services. In this way, broadband network providers, equipment providers, and content service providers form an industrial ecological system.

1.1.2  Portal System Components

As shown in Figure 1-1, a typical portal system consists of four basic components: the authentication client, access device, portal server, and authentication/accounting server.

Figure 1-1 Portal system components

I. Authentication client

Client system installed on a user terminal. It can be a browser using the Hypertext Transfer Protocol (HTTP), or a host running the portal client software. The security authentication of a client depends on the communications between the portal client and the security policy server..

II. Access device

Device for broadband access. It can be a switch or a router and provides these two functions:

l           Before authentication, an access device redirects all HTTP requests from users in the subnet to be authenticated to the portal server. If the authentication succeeds, the users are allowed to access network resources.

l           An access device interacts with the portal server and the authentication/accounting server for authentication and accounting.

III. Portal server

Server that listens to authentication requests from portal authentication clients. It provides free portal services and a web-based authentication interface, and exchanges with the access device the authentication information of authentication clients.

IV. Authentication/accounting server

Server that implements user authentication and accounting through the interaction with the access device.

The interaction procedure of the above four components follows:

1)         When an unauthenticated user enters a website address in the address bar of the IE to access the Internet, an HTTP request is created and sent to the access device, which then redirects the HTTP request to the web authentication homepage of the portal server.

2)         On the authentication homepage, the user enters and submits the authentication information. Then the portal server transfers it to the access device.

3)         Upon receipt of the authentication information, the access device communicates with the authentication/accounting server for authentication and accounting.

4)         If the authentication succeeds, the access device establishes a connection between the user and the Internet so that the user can access the Internet.

 

 

1.1.3  Portal Authentication Mode

There are two kinds of portal authentication: non-Layer 3 authentication and Layer 3 authentication.

I. Non-Layer 3 authentication

Non-Layer 3 authentication falls into two categories:

l           Direct authentication

Before authentication, a user manually configures a public IP address or directly obtains a public IP address through DHCP, and can only access the portal server and predefined free websites. After passing authentication, the user can access the Internet. The process of direct authentication is simpler than that of re-DHCP authentication.

l           Re-DHCP authentication

Before authentication, a user gets a private IP address through DHCP and can only access the portal server and predefined free websites. After passing authentication, the user is assigned a public IP address so that the user can access the Internet. No public IP address is allocated to those who fails authentication. This solves the problem about IP address planning and allocation. This is very useful. For example, a service provider allocates public IP addresses to broadband users in a residential community only when they access external networks.

II. Layer 3 authentication

Layer 3 portal authentication is similar to direct authentication. However, in Layer-3 portal authentication mode, a Layer 3 forwarding device can be present between the authentication client and the access device.

III. Differences between Layer 3 authentication and non-Layer 3 authentication

l           Networking mode

From this point of view, the difference between these two authentication modes lies in whether or not a Layer 3 forwarding device can be present between the authentication client and the access device. The former supports Layer 3 forwarding devices, while the latter does not.

l           User identifier

In Layer 3 authentication mode, a user is uniquely identified by the IP address because the mode supports Layer 3 forwarding devices between the authentication client and the access device, but the access device may not learn the MAC address of the authentication client. In the non-Layer-3 authentication mode, a user is uniquely identified by the combination of its IP address and MAC address because the access device can learn the MAC address of the authentication client.

As mentioned above, it is possible to trigger a new portal authentication in Layer-3 authentication mode when the MAC address of the authentication client is unaltered but the IP address is changed. This is not the case in non-Layer-3 authentication mode. Instead, a new portal authentication will be triggered in the non-Layer-3 authentication mode only when the MAC and IP addresses of the authentication client are both changed.

 

 

1.1.4  Portal Authentication Process

Direct authentication and Layer 3 portal authentication share the same authentication process. When it comes to re-DHCP authentication, the process is different for the presence of two address allocation procedures.

I. Direct authentication/Layer 3 portal authentication process

Figure 1-2 Direct authentication/Layer 3 portal authentication process

For normal portal authentication, the direct authentication/Layer 3 portal authentication process is as follows:

1)         A portal user initiates an authentication request through HTTP. When HTTP packets arrive at the access device, the access device allows those destined for the portal server or predefined free websites to pass, but redirects those destined for other websites to the portal server. The portal server provides a web page for the user to enter the username and password for authentication.

2)         The portal server and the access device exchange messages through challenge handshake authentication protocol (CHAP) authentication. For password authentication protocol (PAP) authentication, this step is skipped.

3)         The portal server assembles the username and password into an authentication request message and sends it to the access device. Meanwhile, the portal server starts a timer to wait for an authentication acknowledgment message.

4)         The access device and the RADIUS server exchange RADIUS packets.

5)         The access device sends an authentication acknowledgment message to the portal server.

6)         The portal server sends an authentication success message to the authentication client to notify it of login success.

7)         The portal server sends an authentication acknowledgment affirmation message to the access device.

II. Re-DHCP authentication process

Figure 1-3 Re-DHCP authentication process

For normal portal authentication, the re-DHCP authentication process is as follows:

Step 1 through step 6 are the same as those in the direct authentication/Layer 3 portal authentication process.

7)         After receiving an authentication success message, the authentication client obtains a new public IP address through DHCP and notifies the portal server that it has obtained a public IP address.

8)         The portal server notifies the access device that the authentication client has obtained a new public IP address.

9)         The access device checks ARP packets to see whether the user IP address is changed. If so, the access device notifies the portal server of the change.

10)     The portal server notifies the authentication client of login success.

11)     The portal server sends a user IP address change acknowledgment message to the access device.

1.2  Portal Configuration Task List

Task	Remarks
Basic Portal Configuration	Required
Configuring an Authentication-Free Rule	Optional
Configuring an Authentication Subnet	Optional
Forcing a User to Log Out	Optional

 

1.3  Basic Portal Configuration

1.3.1  Configuration prerequisites

The portal feature provides a solution for user authentication. However, the portal feature cannot implement this solution by itself. Currently, RADIUS authentication is required to cooperate with the portal feature to complete user authentication.

The prerequisites for portal authentication are as follows:

l           The portal-enabled interface is configured with a valid IP address or it has obtained a valid IP address through DHCP.

l           The portal server and the RADIUS server have been installed and configured properly.

l           If RADIUS authentication is adopted, username and password are configured on the RADIUS server, and the RADIUS client configurations are performed on the device. For information about RADIUS client configuration, refer to AAA RADIUS HWTACACS Configuration in Security Volume.

1.3.2  Configuration Procedure

Follow these steps to perform basic portal configuration:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Configure a portal server	portal server server-name ip ip-address [ key key-string | port port-id | url url-string ] *	Required By default, no portal server is configured.
Enter VLAN interface view	interface interface-type interface-number	—
Enable portal authentication on the interface	portal server server-name method layer3 [ service-type normal ]	Required Disabled by default

 

 

1.4  Configuring an Authentication-Free Rule

An authentication-free rule allows the specific users to access external websites, depending on the source and destination information specified in the authentication-free rule. Packets in compliance with the authentication-free rule will not trigger the portal authentication so that the users can directly access the Internet.

Follow these steps to configure an authentication-free rule:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Configure a portal-authentication-free rule	portal free-rule rule-number { destination { any | ip { ip-address mask { mask-length | netmask } | any } } | source { any | [ interface interface-type interface-number | ip { ip-address mask { mask-length | mask } | any } | vlan vlan-id ] * } } *	Required

 

 

1.5  Configuring an Authentication Subnet

With an authentication subnet configured, only packets from the users whose IP addresses are within this authentication subnet trigger a forced portal authentication. If the IP addresses of users, for whom a forced authentication will be performed, neither satisfy the authentication-free rule nor fall within the authentication subnet, the packets are discarded.

Follow these steps to configure an authentication subnet:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter VLAN interface view	interface interface-type interface-number	—
Configure an authentication subnet	portal auth-network network-address { mask-length | mask }	Optional By default, the IP address of the authentication subnet is 0.0.0.0/0, which indicates that any source IP address will be authenticated.

 

1.6  Forcing a User to Log Out

By forcing a user with the specified IP address to log out, you can terminate the authentication for the user or delete the user even if the user passes authentication.

Follow these steps to force a user to log out:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Force a user attached to the access device to log out.	portal delete-user { ip-address | all | interface interface-type interface-number }	Required

 

1.7  Displaying and Maintaining Portal

To do…	Use the command…	Remarks
Display the ACLs on the specified interface	display portal acl { all | dynamic | static } interface interface-type interface-number	Available in any view
Display the portal connection statistics on the specified interface or all interfaces	display portal connection statistics { all | interface interface-type interface-number }	Available in any view
Displays the information of a portal-authentication-free rule	display portal free-rule [ rule-number ]	Available in any view
Display the portal configuration on the specified interface	display portal interface interface-type interface-number	Available in any view
Display information about the portal server	display portal server [ server-name ]	Available in any view
Display the portal server statistics on the specified interface or all interfaces	display portal server statistics { all | interface interface-type interface-number }	Available in any view
Display TCP spoofing statistics	display portal tcp-cheat statistics	Available in any view
Display portal user information on the specified interface or all interfaces	display portal user { all | interface interface-type interface-number }	Available in any view
Clear the portal connection statistics on the specified interface or all interfaces	reset portal connection statistics {all | interface interface-type interface-number }	Available in user view
Clear the portal server statistics on the specified interface or all interfaces	reset portal server statistics { all | interface interface-type interface-number }	Available in user view
Clear TCP spoofing statistics	reset portal tcp-cheat statistics	Available in user view

 

1.8  Portal Configuration Example

1.8.1  Layer 3 Portal Direct Authentication Configuration Example

I. Network requirements

Switch A supports portal authentication. The user PC is connected to Switch A through Switch B.

l           Switch A is configured to adopt Layer 3 portal authentication. Before portal authentication, users can access only the portal server. After passing the portal authentication, they can access external networks.

l           A RADIUS server serves as the authentication/accounting server.

II. Network diagram

Figure 1-4 Network diagram for Layer 3 portal authentication

III. Configuration procedure

 

 

Follow these steps on Switch A.

1)         Configure a RADIUS scheme

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

<Sysname> system-view

[Sysname] radius scheme rs1

# Set the server type to extended.

[Sysname-radius-rs1] server-type extended

# Configure the primary authentication server, the primary accounting server, and the keys for both servers to communicate.

[Sysname-radius-rs1] primary authentication 192.168.0.112

[Sysname-radius-rs1] primary accounting 192.168.0.112

[Sysname-radius-rs1] key accounting radius

[Sysname-radius-rs1] key authentication radius

# Specify that the ISP domain name should not be included in the username sent to the RADIUS server.

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

[Sysname-radius-rs1] quit

2)         Configure an authentication domain.

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

[Sysname] domain dm1

# Configure the RADIUS scheme named rs1 in the ISP domain.

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

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

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

[Sysname-isp-dm1] quit

# Configure dm1 as the default ISP domain where all access users share the default authentication and accounting modes.

[Sysname] domain default enable dm1

3)         Configure portal authentication

# Configure the portal server as follows:

l           Name: newpt

l           IP address: 192.168.0.111

l           Key: portal

l           Port number: 50100

l           URL: http://192.168.0.111/portal.

<Sysname> system-view

[Sysname] portal server newpt ip 192.168.0.111 key portal port 50100 url http://192.168.0.111/portal

# Enable portal authentication on the interface attached to Switch B.

[Sysname] interface Vlan-interface 4

[Sysname–Vlan-interface4] ip address 20.20.20.1 255.255.255.0

[Sysname–Vlan-interface4] portal server newpt method layer3 service-type normal

[Sysname–Vlan-interface4] quit

# Configure the IP address of the interface which communicates with the portal server.

[Sysname] interface Vlan-interface 2

[Sysname–Vlan-interface2] ip address 192.168.0.100 255.255.255.0

Configure a default route to the network 192.168.0.0/24 on Switch B, setting the next hop to 20.20.20.1. The configuration procedure is omitted.

1.9  Troubleshooting Portal

1.9.1  Inconsistent Keys on the Access Device and the Portal Server

I. Symptom

When a user is forced to access the portal server, the portal server neither displays a portal authentication page nor prompt error messages. The web page of the portal server that the user logs in to is blank.

II. Analysis

It is possible that inconsistent portal keys on the access device and the portal server causes an error when the portal server verifies messages. As a result, the portal server does not display an authentication page.

III. Solution

Use the display portal server command to display the key of the portal server on the access device and use the portal server command to modify the key in system view. Or view and modify the key of the access device on the portal server to ensure their keys are consistent.

1.9.2  Incorrect Server Port Number on the Access Device

I. Symptom

After a user passes the portal authentication, you cannot force the user to log out by executing the portal delete-user command on the access device, but the user can log out by using the disconnect attribute on the authentication client.

II. Analysis

When you execute the portal delete-user command on the access device to force the user to log out, the access device actively sends a REQ_LOGOUT message to the portal server. The default listening port of the portal server is 50100. However, if the listening port configured on the access device is not 50100, the destination port of the REQ_LOGOUT message is not the actual listening port on the server. Thus, the portal server cannot receive the REQ_LOGOUT message. As a result, you cannot force the user to log out the portal server.

When the user uses the disconnect attribute on the client to log out, the portal server actively sends a REQ_LOGOUT message to the access device. The source port is 50100 and the destination port of the ACK_LOGOUT message from the access device is the source port of the REQ_LOGOUT message so that the portal server can receive the ACK_LOGOUT message correctly, no matter whether the listening port is configured on the access device. Therefore, the user can log out the portal server.

III. Solution

Use the display portal server command to display the listening port of the portal server on the access device and use the portal server command in the system view to modify it to ensure that it is the actual listening port of the portal server.