Login
| Title | Size | Downloads |
|---|---|---|
| 17-Portal Configuration.pdf | 232.37 KB |
- Table of Contents
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 17-Portal Configuration | 232.37 KB |
Table of Contents
Chapter 1 Portal Configuration
1.1.2 Introduction to EAD-Supported Portal
1.1.3 Portal System Components
1.1.4 Portal Authentication Modes
1.1.5 Portal Authentication Process
1.2 Portal Configuration Task List
1.3 Basic Portal Configuration
1.3.1 Configuration Prerequisites
1.4 Configuring a Portal-Free Rule
1.5 Configuring an Authentication Subnet
1.7 Displaying and Maintaining Portal
1.8 Portal Configuration Examples
1.8.1 Example for Configuring Direct Portal Authentication
1.8.2 Example for Configuring Re-DHCP Portal Authentication
1.8.3 Example for Configuring Layer 3 Portal Authentication
1.8.4 Example for Configuring Direct EAD-Supported Portal Authentication
1.9.1 Inconsistent Keys on the Access Device and the Portal Server
1.9.2 Incorrect Server Port Number on the Access Device
Chapter 1 Portal Configuration
When configuring portal, go to these sections for information you are interested in:
l Portal Configuration Task List
l Displaying and Maintaining Portal
l Portal Configuration Examples
1.1 Portal Overview
This section covers these topics:
l Portal Authentication Process
1.1.1 Introduction to Portal
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, 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 Introduction to EAD-Supported Portal
By forcing users to implement patching and anti-virus policies, EAD-supported portal helps users to defend against viruses. The main functions are described as follows:
l Security authentication mechanism: The security authentication mechanism works after the identity authentication process to check that the required anti-virus software, virus definition updates and OS patches are installed, and no unauthorized software is installed on the terminal of a user.
l Resource access limit: A user passing identity authentication can access only network resources like the anti-virus server or OS patch server, which are called the restricted resources. Only users passing security authentication can access more network resources, which are called the unrestricted resources.
1.1.3 Portal System Components
As shown in Figure 1-1, a typical portal system consists of five basic components: authentication client, access device, portal server, authentication/accounting server, and security policy server.
Figure 1-1 Portal system components
I. Authentication client
Host of a user to be authenticated, which is running the Hypertext Transfer Protocol (HTTP), the Secure HTTP (HTTPS) protocol, or the portal client software. To support EAD, the host must run the portal client software supporting EAD.
II. Access device
Device for broadband access. It can be a switch or a router that provides three functions:
l Before authentication, redirecting all HTTP requests from a user to the portal server if the user uses IE browser to access Internet, or returning the IP address and port of the portal server to the user if the user uses portal client to establish a portal connection.
l During authentication, interacting with the portal server, the authentication/accounting server, and the security policy server for identity authentication, security authentication and accounting.
l After authentication, allowing users to access the authorized Internet resources.
III. Portal server
Server that listens to authentication requests from portal authentication clients and exchanges client authentication information with the access device. It provides free portal services and a web-based authentication interface.
IV. Authentication/accounting server
Server that implements user authentication and accounting through interaction with the access device.
V. Security policy server
Server that interacts with portal clients and access devices for security authentication and resource authorization.
The above five components interact in the following procedure:
1) For an unauthenticated user:
l When the user enters a website address in the address bar of 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.
l When the user uses the portal client software to establish a portal connection, a TCP/UDP request is created and sent to the access device. When the access device detects the TCP/UDP request, it sends an authentication packet to the portal client. An authentication dialog box will then pop up at the client.
2) On the authentication homepage/authentication dialog box, the user enters and submits the authentication information, which the portal server then transfers to the access device.
3) Upon receipt of the authentication information, the access device communicates with the authentication/accounting server for authentication and accounting.
4) If the authentication succeeds:
l For a user using IE, the access device allows the user to access the Internet.
l For a user using the portal client software, the portal client, access device and security policy server communicate to check the security status of the client and determine the access rights of the user.
Caution:
l Because a portal client uses an IP address as its ID, ensure that there is no Network Address Translation (NAT) device between the authentication client, access device, portal server, and authentication/accounting server when deploying portal authentication. This is to avoid authentication failure due to NAT operations.
l Currently, only a RADIUS server can serve as the authentication/accounting server in a portal system.
1.1.4 Portal Authentication Modes
Portal authentication supports two modes: non-Layer 3 authentication and Layer 3 authentication.
I. Non-Layer 3 authentication
Non-Layer 3 authentication falls into two categories: direct authentication and Re-DHCP authentication.
l Direct authentication
Before authentication, a user manually configures a public IP address or directly obtains a public IP address through DHCP, and can access only the portal server and predefined free websites. After passing authentication, the user can access the 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 access only the portal server and predefined free websites. After passing authentication, the user is allocated a public IP address and 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 and proves to be useful. For example, a service provider can allocate public IP addresses to broadband users only when they access networks beyond the residential community network.
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 and non-Layer 3 authentication modes
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 client is uniquely identified by an IP address. This is because the mode supports Layer 3 forwarding devices between the authentication client and the access device but the access device does not learn the MAC address of the authentication client. In non-Layer 3 authentication mode, a client 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.
Due to the above differences, when the MAC address of an authentication client remains the same but the IP address changes, a new portal authentication will be triggered in Layer-3 authentication mode but will not be triggered in non-Layer 3 authentication mode. In non-Layer 3 authentication mode, a new portal authentication will be triggered only when both the MAC and IP address of the authentication client are changed.
1.1.5 Portal Authentication Process
Direct authentication and Layer 3 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 authentication process
Figure 1-2 Direct authentication/Layer 3 authentication process
For portal authentication, the direct authentication/Layer 3 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.
2) The portal server and the access device exchange Challenge Handshake Authentication Protocol (CHAP) messages. 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 to authenticate the user.
5) If the user passes authentication, the access device sends an authentication acknowledgment message to the portal server.
6) The portal server sends an authentication acknowledgment message to the authentication client to notify it of login success.
7) The portal server sends an affirmation message to the access device.
If EAD is supported, the following two steps are also included:
8) The security policy server exchanges security authentication information with the client to check whether the authentication client meets the security requirements.
9) The security policy server authorizes the user to access unrestricted resources based on the security configuration for the user. The authorization information is stored on the access device and used by the access device to control user access.
II. Re-DHCP authentication process
Figure 1-3 Re-DHCP authentication process
For 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.
1) After receiving an authentication acknowledgment 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.
2) The portal server notifies the access device that the authentication client has obtained a new public IP address.
3) Detecting the change of the IP address by examining ARP packets received, the access device notifies the portal server of the change.
4) The portal server notifies the authentication client of login success.
5) The portal server sends a user IP address change acknowledgment message to the access device.
If EAD is supported, the following two steps are also included:
1) The security policy server exchanges security authentication information with the client to check whether the authentication client meets the security requirements.
2) The security policy server authorizes the user to access unrestricted resources based on the security configuration for the user. The authorization information is stored on the access device and used by the access device to take control of user access.
1.2 Portal Configuration Task List
Complete these tasks to configure portal authentication:
|
Task |
Remarks |
|
Required |
|
|
Optional |
|
|
Optional |
|
|
Optional |
1.3 Basic Portal Configuration
1.3.1 Configuration Prerequisites
The portal feature provides a solution for user authentication and security authentication. However, the portal feature cannot implement this solution by itself. Currently, RADIUS authentication needs to be configured on the access device to cooperate with the portal feature to complete user authentication.
The prerequisites for portal authentication are as follows:
l The portal-enabled interfaces of the access device are configured with valid IP addresses or have obtained valid IP addresses through DHCP.
l The portal server and the RADIUS server have been installed and configured properly.
l With re-DHCP authentication, the invalid IP address check function of DHCP relay is enabled on the access device, and the DHCP server is installed and configured properly.
l With RADIUS authentication, usernames and passwords of the users are configured on the RADIUS server, and the RADIUS client configurations are performed on the access device. For information about RADIUS client configuration, refer to AAA-RADIUS-HWTACACS Configuration in this manual.
l To implement EAD-supported portal authentication, you need to install and configure the security policy server and ensure that the ACLs configured on the access device correspond to those specified for restricted resources and unrestricted resources on the security policy server respectively. For information about security policy server configuration, refer to AAA RADIUS HWTACACS Configuration in this manual.
& Note:
l For configuration about the security policy server, refer to CAMS EAD Security Policy Component User Manual.
l The ACL for restricted resources and that for unrestricted resources correspond to isolation ACL and security ACL on the security policy server respectively.
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 interface view |
interface interface-type interface-number |
— |
|
Enable portal authentication on the interface |
portal server server-name method { direct | layer3 | redhcp } |
Required Disabled by default |
Caution:
l The destination port number that the device uses for sending packets to the portal server unsolicitedly must be the same as that the remote portal server actually uses.
l The portal server parameters are modifiable. However, if the portal server is applied to an interface and portal authentication has been enabled on the interface, you cannot remove the portal server; if there are users on the interface, you cannot modify the parameters.
l The portal server to be referenced must exist.
l Only Layer 3 authentication mode can be used in applications with Layer 3 forwarding devices present between the authentication clients and the access device. However, Layer-3 authentication does not require any Layer-3 forwarding devices between the access device and the authentication clients.
l In re-DHCP authentication mode, a user is allowed to send packets using a public IP address before portal authentication, but the corresponding response packets are restricted.
1.4 Configuring a Portal-Free Rule
A portal-free rule allows specified users to access specified external websites without portal authentication. Packets matching a portal-free rule will not trigger portal authentication and the users can directly access the specified external websites.
Follow these steps to configure a portal-free rule:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Configure a portal-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 } | mac mac-address | vlan vlan-id ] * } } * |
Required |
& Note:
l If you specify both a VLAN and an interface in a portal-free rule, the interface must belong to the VLAN.
l You cannot configure two or more portal-free rules with the same filtering conditions. Otherwise, the system prompts that the rule already exists.
1.5 Configuring an Authentication Subnet
By configuring authentication subnets, you specify that only packets from users on the authentication subnets trigger portal authentication. Packets that are neither from portal-free users nor from authentication subnets are discarded.
Follow these steps to configure an authentication subnet:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter interface view |
interface interface-type interface-number |
— |
|
Configure an authentication subnet |
portal auth-network network-address { mask-length | mask } |
Optional By default, the authentication subnet is 0.0.0.0/0, which means that users with any source IP addresses are to be authenticated. |
& Note:
l Configuration of authentication subnets applies to only Layer 3 portal authentication.
l In direct authentication mode, the authentication subnet is 0.0.0.0/0.
l In re-DHCP authentication mode, the authentication subnet of an interface is the subnet to which the private IP address of the interface belongs.
1.6 Logging out Users
Logging out a user terminates the authentication process for the user or removes the user.
Follow these steps to log out users:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Log out users |
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 a specified interface |
display portal acl { all | dynamic | static } interface interface-type interface-number |
Available in any view |
|
Display portal connection statistics on a specified interface or all interfaces |
display portal connection statistics { all | interface interface-type interface-number } |
Available in any view |
|
Display information about a portal-free rule or all portal-free rules |
display portal free-rule [ rule-number ] |
Available in any view |
|
Display the portal configuration of a specified interface |
display portal interface interface-type interface-number |
Available in any view |
|
Display information about a specified portal server or all portal servers |
display portal server [ server-name ] |
Available in any view |
|
Display portal server statistics on a 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 information about portal users on a specified interface or all interfaces |
display portal user { all | interface interface-type interface-number } |
Available in any view |
|
Clear portal connection statistics on a specified interface or all interfaces |
reset portal connection statistics {all | interface interface-type interface-number } |
Available in user view |
|
Clear portal server statistics on a 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 Examples
1.8.1 Example for Configuring Direct Portal Authentication
I. Network requirements
l The switch is configured for direct authentication. Before portal authentication, users can access only the portal server. After passing 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 configuring direct portal authentication
III. Configuration procedure
& Note:
You need to configure IP addresses for the devices as shown in Figure 1-4 and ensure that routes are available between devices.
Configure the access device:
1) Configure a RADIUS scheme
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Set the server type to extended.
[Switch-radius-rs1] server-type extended
# Configure the primary authentication server, the primary accounting server, and the keys for the servers to communicate.
[Switch-radius-rs1] primary authentication 192.168.0.112
[Switch-radius-rs1] primary accounting 192.168.0.112
[Switch-radius-rs1] key authentication radius
[Switch-radius-rs1] key accounting radius
# Specify that the ISP domain name should not be included in the username sent to the RADIUS server.
[Switch-radius-rs1] user-name-format without-domain
[Switch-radius-rs1] quit
2) Configure an authentication domain
# Create an ISP domain named dm1 and enter its view.
[Switch] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-isp-dm1] quit
# Configure dm1 as the default ISP domain, allowing all users to share the default authentication and accounting modes.
[Switch] 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.
[Switch] 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 connecting the host.
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] ip address 2.2.2.1 255.255.255.0
[Switch–Vlan-interface100] portal server newpt method direct
[Switch] quit
# Configure the IP address of the interface connected with the portal server.
[Switch] interface vlan-interface 2
[Switch–Vlan-interface2] ip address 192.168.0.100 255.255.255.0
[Switch–Vlan-interface2] quit
1.8.2 Example for Configuring Re-DHCP Portal Authentication
I. Network requirements
l The switch is configured for re-DHCP authentication. Users obtain IP addresses through the DHCP server. Before portal authentication, they get private IP addresses. After passing portal authentication, they get public IP addresses and then can access the Internet.
l A RADIUS server serves as the authentication/accounting server.
II. Network diagram
Figure 1-5 Network diagram for configuring re-DHCP portal authentication
III. Configuration procedure
& Note:
l For re-DHCP authentication, you need to configure a public address pool (20.20.20.0/24, in this example) and a private address pool (10.0.0.0/24, in this example) on the DHCP server. The configuration steps are omitted. For DHCP configuration information, refer to DHCP Configuration in this manual.
l For re-DHCP authentication, the access device must be configured as a DHCP relay agent (instead of a DHCP server) and the portal-enabled interface must be configured with a primary IP address (a public IP address) and a secondary IP address (a private IP address).
l You need to configure IP addresses for the devices as shown in Figure 1-5 and ensure that routes are available between devices.
l The following describes only the configurations related to re-DHCP authentication mode. For configurations about the RADIUS scheme and ISP domain, refer to Example for Configuring Direct Portal Authentication.
Configure the access device:
#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.
<switch> system-view
[Switch] portal server newpt ip 192.168.0.111 key portal port 50100 url http://192.168.0.111/portal
# Configure the access device as a DHCP relay agent, and enable the invalid address check function.
[Switch] dhcp enable
[Switch] dhcp relay server-group 0 ip 192.168.0.112
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] ip address 20.20.20.1 255.255.255.0
[Switch–Vlan-interface100] ip address 10.0.0.1 255.255.255.0 sub
[Switch-Vlan-interface100] dhcp select relay
[Switch-Vlan-interface100] dhcp relay server-select 0
[Switch-Vlan-interface100] dhcp relay address-check enable
# Enable re-DHCP portal authentication on the interface connecting the host.
[Switch–Vlan-interface100] portal server newpt method redhcp
[Switch–Vlan-interface100] quit
# Configure the IP address of the interface connected with the portal server.
[Switch] interface vlan-interface 2
[Switch–Vlan-interface2] ip address 192.168.0.100 255.255.255.0
[Switch–Vlan-interface2] quit
1.8.3 Example for Configuring Layer 3 Portal Authentication
I. Network requirements
l Switch A is configured for Layer 3 portal authentication. Before portal authentication, users can access only the portal server. After passing portal authentication, they can access external networks.
l The host accesses Switch A through Switch B
l A RADIUS server serves as the authentication/accounting server.
II. Network diagram
Figure 1-6 Network diagram for Layer 3 portal authentication
III. Configuration procedure
& Note:
l You need to configure IP addresses for the devices as shown in Figure 1-6 and ensure that routes are available between devices.
l The following describes only the major configurations related to Layer 3 portal authentication. For configurations about the RADIUS scheme and ISP domain, refer to Example for Configuring Direct Portal Authentication.
Configure Switch A:
# 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.
<SwitchA> system-view
[SwitchA] 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 connecting Switch B.
[SwitchA] interface vlan-interface 4
[SwitchA–Vlan-interface4] ip address 20.20.20.1 255.255.255.0
[SwitchA–Vlan-interface4] portal server newpt method layer3
[SwitchA–Vlan-interface4] quit
# Configure the IP address of the interface connected with the portal server.
[SwitchA] interface vlan-interface 2
[SwitchA–Vlan-interface2] ip address 192.168.0.100 255.255.255.0
[SwitchA–Vlan-interface2] quit
On Switch B, you need to configure a default route to subnet 192.168.0.0/24, setting the next hop as 20.20.20.1. The configuration steps are omitted.
1.8.4 Example for Configuring Direct EAD-Supported Portal Authentication
I. Network requirements
l The switch is configured for direct EAD-supported portal authentication. When users have passed identity authentication but have not passed security authentication, they can access only subnet 192.168.0.0/24. After passing security authentication, they can access unrestricted Internet resources.
l A RADIUS server serves as the authentication/accounting server.
l A security policy server is required.
II. Network diagram
Figure 1-7 Configure direct EAD-supported portal authentication
III. Configuration procedure
& Note:
You need to configure IP addresses for the devices as shown in Figure 1-7 and ensure that routes are available between devices.
Configure the switch:
1) Configure a RADIUS scheme
# Create a RADIUS scheme named rs1 and enter its view.
<Switch> system-view
[Switch] radius scheme rs1
# Set the server type to extended.
[Switch-radius-rs1] server-type extended
# Configure the primary authentication server, the primary accounting server, and the keys for the servers to communicate.
[Switch-radius-rs1] primary authentication 192.168.0.112
[Switch-radius-rs1] primary accounting 192.168.0.112
[Switch-radius-rs1] key accounting radius
[Switch-radius-rs1] key authentication radius
[Switch-radius-rs1] user-name-format without-domain
# Configure the IP address of the security policy server.
[Switch-radius-rs1] security-policy-server 192.168.0.113
[Switch-radius-rs1] quit
2) Configure an authentication domain
# Create an ISP domain named dm1 and enter its view.
[Switch] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[Switch-isp-dm1] authentication portal radius-scheme rs1
[Switch-isp-dm1] authorization portal radius-scheme rs1
[Switch-isp-dm1] accounting portal radius-scheme rs1
[Switch-isp-dm1] quit
# Configure dm1 as the default ISP domain, allowing all users to share the default authentication and accounting modes.
[Switch] domain default enable dm1
3) Configure the ACL (ACL 3000 ) for restricted resources and the ACL (ACL 3001) for unrestricted resources
& Note:
On the security policy server, you need to specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL.
[Switch] acl number 3000
[Switch-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[Switch-acl-adv-3000] quit
[Switch] acl number 3001
[Switch-acl-adv-3001] rule permit ip
[Switch-acl-adv-3001] quit
4) 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.
[Switch] 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 connecting the host.
[Switch] interface vlan-interface 100
[Switch–Vlan-interface100] ip address 2.2.2.1 255.255.255.0
[Switch–Vlan-interface100] portal server newpt method direct
[Switch] quit
# Configure the IP address of the interface connected with the portal server.
[Switch] interface vlan-interface 2
[Switch–Vlan-interface2] ip address 192.168.0.100 255.255.255.0
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 displays neither the portal authentication page nor any error message. What the user sees is a blank web page.
II. Analysis
The keys configured on the access device and the portal server are inconsistent, causing CHAP message exchange failure. As a result, the portal server does not display the authentication page.
III. Solution
l Use the display portal server command to display the key for the portal server on the access device and view the key for the access device on the portal server.
l Use the portal server command to modify the key on the access device or modify the key for the access device on the portal server to ensure that the 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.
