- Table of Contents
-
- 10-Security Configuration Guide
- 00-Preface
- 01-AAA Configuration
- 02-802.1X Configuration
- 03-MAC Authentication Configuration
- 04-Portal Configuration
- 05-Password Control Configuration
- 06-Public Key Configuration
- 07-IPsec Configuration
- 08-SSH Configuration
- 09-Packet-Filter Firewall Configuration
- 10-ALG Configuration
- 11-Session Management Configuration
- 12-TCP and ICMP Attack Protection Configuration
- 13-IP Source Guard Configuration
- 14-ARP Attack Protection Configuration
- 15-URPF Configuration
- 16-COPS Configuration
- 17-FIPS Configuration
- 18-PKI Configuration
- Related Documents
-
Title | Size | Download |
---|---|---|
04-Portal Configuration | 469.86 KB |
Contents
Configuring portal authentication·
Portal authentication overview
Portal authentication across VPNs
Portal configuration task list
Specifying a portal server for portal authentication
Enabling portal authentication
Controlling access of portal users
Configuring a portal-free rule
Configuring an authentication subnet
Setting the maximum number of online portal users
Specifying an authentication domain for portal users
Configuring RADIUS related attributes
Specifying NAS-Port-Type for an interface
Specifying a NAS ID profile for an interface
Specifying a source IP address for outgoing portal packets
Configuring portal detection functions
Configuring the portal server detection function
Configuring portal user information synchronization
Displaying and maintaining portal
Configuring re-DHCP portal authentication
Configuring cross-subnet portal authentication
Configuring re-DHCP portal authentication with extended functions
Configuring cross-subnet portal authentication with extended functions
Configuring portal server detection and portal user information synchronization
Cross-subnet portal authentication across VPNs
Inconsistent keys on the router (access device) and the portal server
Incorrect server port number on the router (access device)
Configuring portal authentication
Portal authentication overview
With portal authentication, an access device redirects all users to the portal authentication page. All users can access the free services provided on the portal website; but to access the Internet, a user must pass portal authentication.
A user can access a known portal website and enter a username and password for authentication. This authentication mode is called active authentication. There is another authentication mode, forced authentication, in which the access device forces a user who is trying to access the Internet through Hypertext Transfer Protocol (HTTP) to log on 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 and personalized services. In this way, broadband network providers, equipment vendors, and content service providers form an industrial ecological system.
Extended portal functions
By forcing patching and anti-virus policies, extended portal functions help users to defend against viruses. Portal authentication supports the following extended functions:
· Security check—Works after identity authentication succeeds to check whether the required anti-virus software, virus definition file, and operating system (OS) patches are installed, and whether there is any unauthorized software installed on the user host.
· Resource access restriction—A user passing identity authentication can access only network resources in the quarantined area, such as the anti-virus server and the patch server. Only users passing both identity authentication and security check can access restricted network resources.
Portal system components
A typical portal system comprises these basic components: authentication client, access device, portal server, authentication/accounting server, and security policy server.
Figure 1 Portal system components
Authentication client
An authentication client is an entity seeking access to network resources. It is typically an end-user terminal, such as a PC. A client can use a browser or a portal client software for portal authentication. The security check for a client is implemented through the communications between the client and the security policy server.
Access device
An access device controls user access. It can be a switch or router that provides the following three functions:
· Redirecting all HTTP requests from unauthenticated users to the portal server.
· Interacting with the portal server, the security policy server, and the authentication/accounting server for identity authentication, security check, and accounting.
· Allowing users who have passed identity authentication and security check to access granted Internet resources.
Portal server
A portal server listens to authentication requests from authentication clients and exchanges client authentication information with the access device. It provides free portal services and pushes web authentication pages to users.
Authentication/accounting server
An authentication/accounting server implements user authentication and accounting through interaction with the access device.
Security policy server
A security policy server interacts with authentication clients and access devices for security check and resource authorization.
The components of a portal system interact in the following procedure:
1. When an unauthenticated user enters a website address in the browser’s address bar to access the Internet, an HTTP request is created and sent to the access device, which redirects the HTTP request to the portal server’s web authentication homepage. For extended portal functions, authentication clients must run the portal client software.
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. After successful authentication, the access device checks whether there is a corresponding security policy for the user. If not, it allows the user to access the Internet. Otherwise, the client communicates with the access device and the security policy server for security check. If the client passes security check, the security policy server authorizes the user to access the Internet resources.
|
NOTE: · Portal authentication supports NAT traversal whether it is initiated by a web client or an H3C iNode client. When the portal authentication client is on a private network, but the portal server is on a public network and the access device is enabled with NAT, network address translations performed on the access device do not affect portal authentication. However, in such a case, H3C recommends specifying a public IP address of an interface as the source address of outgoing portal packets. · Only a RADIUS server can serve as the remote authentication/accounting server in a portal system. · To implement security check, the client must be the H3C iNode client. |
Portal authentication modes
The router supports Layer 3 portal authentication. You can enable Layer 3 authentication on an access device’s Layer 3 interfaces that connect authentication clients. Portal authentication performed on a Layer 3 interface can be re-DHCP authentication or cross-subnet authentication. With re-DHCP authentication, no Layer-3 forwarding devices exist between the authentication client and the access device. With cross-subnet authentication, Layer-3 forwarding devices may exist between the authentication client and the access device.
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 network resources. No public IP address is allocated to those who fail authentication. This solves the IP address planning and allocation problem and can 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.
Cross-subnet 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 network resources. Cross-subnet authentication allows Layer 3 forwarding devices to be present between the authentication client and the access device.
In re-DHCP authentication and cross-subnet authentication, the client’s IP address is used for client identification. After a client passes authentication, the access device generates an access control list (ACL) for the client based on the client's IP address to permit packets from the client to go through the access port. Because no Layer 3 devices are present between the authentication clients and the access device in re-DHCP authentication, the access device can directly learn the MAC addresses of the clients, and thus can control the forwarding of packets from clients in a more granular way by also using the learnt MAC addresses.
Portal authentication process
Cross-subnet authentication process
Figure 2 Portal authentication process
Authentication steps
1. An authentication client initiates authentication by sending an HTTP request. When the HTTP packet arrives at the access device, the access device allows it to pass if it is destined for the portal server or a predefined free website, or redirects it to the portal server if it is destined for other websites. The portal server pushes a web authentication page to the user and the user enters 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 reply message.
4. The access device and the RADIUS server exchange RADIUS packets to authenticate the user.
5. The access device sends an authentication reply to the portal server.
6. The portal server sends an authentication success message to the authentication client to notify it of logon success.
7. The portal server sends an authentication reply acknowledgment message to the access device.
With extended portal functions, the process includes additional steps:
8. The security policy server exchanges security check information with the authentication client to check whether the authentication client meets the security requirements.
9. Based on the security check result, the security policy server authorizes the user to access certain resources, and sends the authorization information to the access device. The access device then controls access of the user based on the authorization information.
Re-DHCP authentication process
Figure 3 Re-DHCP authentication process
The re-DHCP authentication takes the following procedure:
The first steps are the same as those in the direct authentication/cross-subnet authentication process.
7. After receiving the 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. Detecting the change of the IP address by examining ARP packets received, the access device notifies the portal server of the change.
10. The portal server notifies the authentication client of logon success.
11. The portal server sends a user IP address change acknowledgment message to the access device.
With extended portal functions, the process includes additional steps:
12. The security policy server exchanges security check information with the authentication client to check whether the authentication client meets the security requirements.
13. Based on the security check result, the security policy server authorizes the user to access certain resources, and sends the authorization information to the access device. The access device then controls access of the user based on the authorization information.
Portal authentication across VPNs
In a scenario where the branches belong to different VPNs that are isolated from each other and all portal users in the branches need to be authenticated by the server at the headquarters, you can deploy portal authentication across MPLS VPNs. As shown in Figure 4, the PE connecting the authentication clients serves as the NAS. The NAS is configured with portal authentication and AAA authentication, both of which support authentication across VPNs. Therefore, the NAS can transparently transmit portal authentication packets of a client in a VPN through the MPLS backbone to the servers in another VPN. This feature implements centralized authentication of clients present in different VPNs and also ensures the separation of packets of different VPNs.
Figure 4 Network diagram for portal authentication across VPNs
|
NOTE: · Portal authentication configured on MCEs can also support authentication across VPNs. For information about MCE, see MPLS Configuration Guide. · For information about AAA implementation across VPNs, see the chapter “Configuring AAA.“ · This feature is not applicable to VPNs with overlapping address spaces. |
Portal configuration task list
Complete these tasks to configure portal authentication:
Task |
Remarks |
|
Required |
||
Optional |
||
Optional |
||
Optional |
||
Optional |
||
Optional |
Basic portal configuration
Configuration prerequisites
The portal feature provides a solution for user authentication and security checking. However, the portal feature cannot implement this solution by itself. RADIUS authentication needs to be configured on the router (access device) to cooperate with the portal feature to complete user authentication.
The prerequisites for portal authentication are as follows:
· The portal server and the RADIUS server have been installed and configured properly.
· With re-DHCP authentication, the IP address check function of the DHCP relay agent is enabled on the access device, and the DHCP server is installed and configured properly.
· The portal client, access device, and servers can reach each other.
· 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, see the chapter “Configuring AAA.“
· To implement extended portal functions, you need install and configure the security policy server, and make sure that the ACLs configured on the access device correspond to those resources in the quarantined area and restricted resources on the security policy server respectively. For information about security policy server configuration on the access device, see the chapter “Configuring AAA.“
Specifying a portal server for portal authentication
This task allows you to specify the portal server parameters for Layer 3 portal authentication, including the portal server's IP address and port number, the shared encryption key, and the URL address for web authentication.
To specify a portal server for portal configuration:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Specify a portal server name and the related parameters. |
portal server server-name ip ip-address [ key key-string | port port-id | url url-string | vpn-instance vpn-instance-name ] * |
By default, no portal server is specified. |
|
NOTE: · The router allows you to specify up to four portal servers. · The configured parameters of a portal server can be modified or deleted only if the portal server is not referenced on any interface. · To make sure that the router can send packets to the portal server in an MPLS VPN, specify the VPN instance to which the portal server belongs when specifying the portal server on the router. |
Enabling portal authentication
Only after you enable portal authentication on an access interface, can the access interface perform portal authentication for connected clients.
Configuration prerequisites
Before enabling portal authentication on an interface, make sure that:
· A valid IP address is configured for the interface or the interface has obtained an IP address.
· The interface is not added to any port aggregation group.
· The portal server to be referenced on the interface exists.
Configuration guidelines
· You cannot enable portal authentication on a Layer 3 interface added to an aggregation group, nor can you add a portal-enabled Layer 3 interface to an aggregation group.
· The destination port number that the router uses for sending packets to the portal server unsolicitedly must be the same as that the remote portal server actually uses.
· The portal server and its parameters can be deleted or modified only when the portal server is not referenced by any interface.
· Cross-subnet authentication mode (portal server server-name method layer3) does not require Layer 3 forwarding devices between the access device and the authentication clients. However, if there are Layer 3 forwarding devices between the authentication client and the access device, you must select the cross-subnet portal authentication mode.
· If you have enabled portal on a VLAN interface, H3C does not recommend applying a user-defined flow template on a port in the VLAN. If a user-defined flow template is required on the port, the user-defined flow template must be defined with the source IP address, destination IP address, destination port number, and protocol type fields; otherwise, the portal function on the VLAN interface will not take effect.
· If you have enabled portal on a routing interface or sub-interface, H3C does not recommend applying a user-defined flow template on the routing interface or sub-interface. If a user-defined flow template is required on the routing interface or sub-interface, the user-defined flow template must be defined with the source IP address, destination IP address, destination port number, and protocol fields; otherwise, the portal function will not take effect.
· In re-DHCP authentication mode, a client can use a public IP address to send packets before passing portal authentication. However, responses to the packets are restricted.
To enable portal authentication:
Step |
Command |
Remarks |
3. Enter system view. |
system-view |
N/A |
4. Enter interface view. |
interface interface-type interface-number |
The interface must be a Layer 3 Ethernet interface. |
5. Enable portal authentication on the interface. |
portal server server-name method { layer3 | redhcp } |
Not enabled by default. |
Controlling access of portal users
Configuring a portal-free rule
A portal-free rule allows specified users to access specified external websites without portal authentication.
The matching items for a portal-free rule include the source and destination IP address, and VLAN. Packets matching a portal-free rule will not trigger portal authentication, and therefore users sending the packets can directly access the specified external websites.
To configure a portal-free rule:
Step |
Command |
1. Enter system view. |
system-view |
2. Configure a portal-free rule. |
portal free-rule rule-number { destination { any | ip { ip-address mask { mask-length | netmask } | any } } | source { any | [ ip { ip-address mask { mask-length | netmask } | any } | vlan vlan-id ] * } } * |
|
NOTE: · You cannot configure two or more portal-free rules with the same filtering conditions. Otherwise, the system prompts that the rule already exists. · No matter whether portal authentication is enabled, you can only add or remove a portal-free rule, rather than modifying it. |
Configuring an authentication subnet
By configuring authentication subnets, you specify that only HTTP packets from users on the authentication subnets can trigger portal authentication. If an unauthenticated user is not on any authentication subnet, the access device discards all the user’s HTTP packets that do not match any portal-free rule.
To configure an authentication subnet:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
N/A |
3. Configure an 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 must pass portal authentication. |
Setting the maximum number of online portal users
You can use this feature to control the total number of online portal users in the system.
To set the maximum number of online portal users allowed in the system:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Set the maximum number of online portal users. |
portal max-user max-number |
By default, the maximum number of online portal users depends on the system working mode: · SPE mode—4096. · SPC mode—7680. · Hybrid mode—7680 when the ACL mode is 1 or 2, and 4096 when the ACL mode is 3 or 4. For information about the working modes, see Fundamentals Configuration Guide. |
|
NOTE: If the maximum number of online portal users specified in the command is less than that of the current online portal users, the command can be executed successfully and will not impact the online portal users, but the system will not allow new portal users to log on until the number drops down below the limit. |
Specifying an authentication domain for portal users
After you specify an authentication domain for portal users on an interface, the router uses the authentication domain for authentication, authorization, and accounting (AAA) of all portal users on the interface, ignoring the domain names carried in the usernames. You can specify different authentication domains for different interfaces as needed.
To specify an authentication domain for portal users on an interface:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
N/A |
3. Specify an authentication domain for portal users on the interface. |
portal domain domain-name |
By default, no authentication domain is specified for portal users. |
|
NOTE: The router selects the authentication domain for a portal user on an interface in this order: the authentication domain specified for the interface, the authentication domain carried in the username, and the system default authentication domain. For information about the default authentication domain, see the chapter “Configuring AAA.” |
Configuring RADIUS related attributes
Specifying NAS-Port-Type for an interface
NAS-Port-Type is a standard RADIUS attribute for indicating the type of a user access port. With this attribute specified on an interface, when a portal user logs on from the interface, the router uses the specified NAS-Port-Type value as that in the RADIUS request that it will send to the RADIUS server.
If NAS-Port-Type is not specified, the router uses the access port type obtained. However, if there are multiple network devices between the Broadband Access Server (BAS, the portal authentication access device) and a portal client, the BAS may not be able to obtain the correct access port information of a user. For example, for a wireless client using portal authentication, the access port type obtained by the BAS may be the type of the wired port that authenticates the user. Therefore, to make sure that the BAS delivers the correct access port information to the RADIUS server, specify the NAS-Port-Type according to the practical access environment.
To specify the NAS-Port-Type value for an interface:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
N/A |
3. Specify the NAS-Port-Type value for the interface. |
portal nas-port-type { ethernet | wireless } |
Not configured by default |
Specifying a NAS ID profile for an interface
In some networks, users’ access points are identified by their access VLANs, and network carriers use NAS-identifiers to identify user access points. With a NAS ID profile specified on an interface, when a user logs in from the interface, the access device will check the specified profile to obtain the NAS ID that is bound with the access VLAN. The value of this NAS ID will be used as that of the NAS-identifier attribute in the RADIUS packets to be sent to the RADIUS server.
A NAS ID profile defines the binding relationship between VLANs and NAS IDs. A NAS ID-VLAN binding is defined by the nas-id id-value bind vlan vlan-id command, which is described in detail in AAA of the Security Command Reference.
If no NAS-ID profile is specified for an interface or no matching binding is found in the specified profile, the device name will be used as the interface’s NAS ID.
To configure a NAS ID profile for an interface:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Create a NAS ID profile and enter NAS ID profile view. |
aaa nas-id profile profile-name |
For more information about the command, see Security Command Reference. |
3. Bind a NAS ID with a VLAN. |
nas-id nas-identifier bind vlan vlan-id |
For more information about the command, see Security Command Reference. |
4. Return to system view. |
quit |
N/A |
5. Enter interface view. |
interface interface-type interface-number |
N/A |
6. Specify a NAS ID profile for the interface. |
portal nas-id-profile profile-name |
By default, an interface is specified with no NAS ID profile. |
Specifying a source IP address for outgoing portal packets
After you specify a source IP address for outgoing portal packets, the IP address is used for packet exchanging between the access device and the portal server.
To specify the source IP address for outgoing portal packets:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
N/A |
3. Specify a source IP address for outgoing portal packets. |
portal nas-ip ip-address |
Optional. By default, no source IP address is specified and the IP address of the user logon interface is used as the source IP address of the portal packets. In NAT environments, H3C recommends specifying the interface’s public IP address as the source IP address of outgoing portal packets. |
Configuring portal detection functions
Configuring the portal server detection function
During portal authentication, if the communication between the access device and portal server is broken off, new portal users will not be able to log on and the online portal users will not be able to log off normally. To address this problem, the access device needs to be able to detect the reachability changes of the portal server timely and take corresponding actions to deal with the changes. For example, once detecting that the portal server is unreachable, the access device will allow portal users to access network resources without authentication. This function is referred to as portal escape. It allows for flexible user access control.
With the portal server detection function, the router (the access device) can detect the status of a specific portal server. The specific configurations include:
1. Detection methods (you can choose either or both)
¡ Probing HTTP connections: The access device periodically sends TCP connection requests to the HTTP service port of the portal servers configured on its interfaces. If the TCP connection with a portal server can be established, the access device considers that the probe succeeds, that is, the HTTP service of the portal server is open and the portal server is reachable. If the TCP connection cannot be established, the access device considers that the probe fails and the portal server is unreachable.
¡ Checking portal heartbeat packets: A portal server that supports the portal heartbeat function (only the iMC portal server supports this function) sends portal heartbeat packets to portal access devices periodically. If an access device receives a portal heartbeat packet or an authentication packet within a probe interval, the access device considers that the probe succeeds and the portal server is reachable; otherwise, it considers that the probe fails and the portal server is unreachable.
2. Probe parameters
¡ Probe interval: Interval at which probe attempts are made.
¡ Maximum number of probe attempts: Maximum number of consecutive probe attempts allowed. If the number of consecutive probes reaches this value, the access device considers that the portal server is unreachable.
3. Actions to be taken when the server reachability status changes (you can choose one or more)
¡ Sending a trap message: When the status of a portal server changes, the access device sends a trap message to the network management server. The trap message indicates the name and current state of the portal server.
¡ Sending a log: When the status of a portal server changes, the access device sends a log message. The log message indicates the portal server’s name and its current state and original state.
¡ Disabling portal authentication (enabling portal escape): When the router detects that a portal server is unreachable, it disables portal authentication on the interfaces configured with the portal server, that is, it allows all portal users on the interfaces to access network resources. Then, if the router receives from the portal server portal heartbeat packets or authentication packets (such as logon requests and logout requests), it re-enables the portal authentication function.
You can configure any combination of the configuration items described above as needed, with respect of the following:
· If both detection methods are specified, a portal server is considered unreachable as long as one detection method fails, and an unreachable portal server is considered recovered only when both detection methods succeed.
· If multiple actions are specified, the router will execute all the specified actions when the status of a portal server changes.
· The detection function configured for a portal server takes effect on an interface only after you enable and reference the portal server on the interface.
To configure the portal server detection function:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure the portal server detection function. |
portal server server-name server-detect method { http | portal-heartbeat } * action { log | permit-all | trap } * [ interval interval ] [ retry retries ] |
Not configured by default. The portal server specified in the command must exist. |
|
NOTE: The portal heartbeat detection method works only when the portal server supports the portal server heartbeat function. Currently, only the portal server of iMC supports this function. To implement detection with this method, you also need to configure the portal server heartbeat function on the iMC portal server and make sure that the product of interval and retry is greater than or equal to the portal server heartbeat interval, and H3C recommends configuring the interval to be greater than the portal server heartbeat interval configured on the portal server. |
Configuring portal user information synchronization
Once the router loses communication with a portal server, the portal user information on the router and that on the portal server may be inconsistent after the communication resumes. To solve this problem, the router provides the portal user information synchronization function. This function is implemented by sending and detecting the portal synchronization packet. The process is as follows:
1. The portal server sends the online user information to the access device (the router) in a user synchronization packet at the user heartbeat interval, which is set on the portal server.
2. Upon receiving the user synchronization packet, the router checks the user information carried in the packet with its own. If the router finds a nonexistent user in the packet, it informs the portal server of the information and the portal server will delete the user. If the router finds that one of its users does not appear in the user synchronization packets within N consecutive synchronization probe intervals (N is equal to the value of retries configured in the portal server user-sync command), it considers that the user does not exist on the portal server and logs the user off.
To configure the portal user information synchronization function:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure the portal user information synchronization function. |
portal server server-name user-sync [ interval interval ] [ retry retries ] |
Not configured by default. The portal server specified in the command must exist. This function can take effect only when the specified portal server is referenced and enabled on the interface connecting the users. |
|
NOTE: · The user information synchronization function requires that a portal server supports the portal user heartbeat function. Only the iMC portal server supports portal user heartbeat. To implement the portal user synchronization function, you also need to configure the user heartbeat function on the portal server and make sure that the product of interval and retry is greater than or equal to the portal user heartbeat interval, and H3C recommends configuring the interval to be greater than the portal user heartbeat interval configured on the portal server. · For redundant user information on the router—information for users who are considered nonexistent on the portal server—the router deletes the information during the (N+1)th interval, where N is equal to the value of retries configured in the portal server user-sync command. |
Logging out portal users
Logging out a user terminates the authentication process for the user or removes the user from the authenticated users list.
To log out users:
Step |
Command |
1. Enter system view. |
system-view |
2. Log out users. |
portal delete-user { ip-address | all | interface interface-type interface-number } |
Displaying and maintaining portal
Task |
Command |
Remarks |
Display the ACLs on a specific interface. |
display portal acl { all | dynamic | static } interface interface-type interface-number [ | { begin | exclude | include } regular-expression ] |
Available in any view |
Display portal connection statistics on a specific interface or all interfaces. |
display portal connection statistics { all | interface interface-type interface-number } [ | { begin | exclude | include } regular-expression ] |
Available in any view |
Display information about a portal-free rule or all portal-free rules. |
display portal free-rule [ rule-number ] [ | { begin | exclude | include } regular-expression ] |
Available in any view |
Display the portal configuration of a specific interface. |
display portal interface interface-type interface-number [ | { begin | exclude | include } regular-expression ] |
Available in any view |
Display information about a specific portal server or all portal servers. |
display portal server [ server-name ] [ | { begin | exclude | include } regular-expression ] |
Available in any view |
Display portal server statistics on a specific interface or all interfaces. |
display portal server statistics { all | interface interface-type interface-number } [ | { begin | exclude | include } regular-expression ] |
Available in any view |
Display TCP spoofing statistics. |
display portal tcp-cheat statistics [ | { begin | exclude | include } regular-expression ] |
Available in any view |
Display information about portal users on a specific interface or all interfaces. |
display portal user { all | interface interface-type interface-number } [ | { begin | exclude | include } regular-expression ] |
Available in any view |
Clear portal connection statistics on a specific interface or all interfaces. |
reset portal connection statistics { all | interface interface-type interface-number } |
Available in user view |
Clear portal server statistics on a specific 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 |
Portal configuration examples
Configuring re-DHCP portal authentication
Network requirements
As shown in Figure 5:
· The host is directly connected to the router and the router is configured for re-DHCP portal authentication. The host is assigned an IP address through the DHCP server. Before passing portal authentication, the host uses an assigned private IP address. After passing portal authentication, it gets a public IP address and then the user can access Internet resources.
· A RADIUS server serves as the authentication/accounting server.
Configuration procedure
|
NOTE: · For re-DHCP portal authentication, 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. (Details not shown) · For re-DHCP portal authentication, the router must be configured as a DHCP relay agent 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). For DHCP relay configuration information, see Layer 3—IP Services Configuration Guide. · Make sure that the IP address of the portal device added on the portal server is the public IP address of the interface connecting users (20.20.20.1 in this example), the private IP address range for the IP address group associated with the portal device is the private network segment where the users reside (10.0.0.0/24 in this example), and the public IP address range for the IP address group is the public network segment 20.20.20.0/24. · Configure IP addresses for the router and servers as shown in Figure 5 and make sure that the host, router, and servers can reach each other. · Configure the RADIUS server properly to provide normal authentication/accounting functions for users. |
Configure the router:
1. Configure a RADIUS scheme.
# Create a RADIUS scheme named rs1, and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the CAMS or iMC server, set the server type to extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.
[Router-radius-rs1] primary authentication 192.168.0.113
[Router-radius-rs1] primary accounting 192.168.0.113
[Router-radius-rs1] key authentication radius
[Router-radius-rs1] key accounting radius
# Specify to exclude ISP domain names from the usernames to be sent to the RADIUS server.
[Router-radius-rs1] user-name-format without-domain
[Router-radius-rs1] quit
2. Configure an authentication domain
# Create an ISP domain named dm1 and enter its view.
[Router] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] accounting portal radius-scheme rs1
[Router-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without any ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user.
[Router] domain default enable dm1
3. Configure portal authentication
# Configure the portal server as follows:
¡ Name: newpt
¡ IP address: 192.168.0.111
¡ Key: portal
¡ Port number: 50100
¡ URL: http://192.168.0.111:8080/portal.
[Router] portal server newpt ip 192.168.0.111 key portal port 50100 url http://192.168.0.111:8080/portal
# Configure the router as a DHCP relay agent, and enable the IP address match check function.
[Router] dhcp enable
[Router] dhcp relay server-group 0 ip 192.168.0.112
[Router] interface Gigabitethernet 3/1/2
[Router–GigabitEthernet3/1/2] ip address 20.20.20.1 255.255.255.0
[Router–GigabitEthernet3/1/2] ip address 10.0.0.1 255.255.255.0 sub
[Router-GigabitEthernet3/1/2] dhcp select relay
[Router-GigabitEthernet3/1/2] dhcp relay server-select 0
[Router-GigabitEthernet3/1/2] dhcp relay address-check enable
# Enable re-DHCP portal authentication on the interface connecting the host.
[Router–GigabitEthernet3/1/2] portal server newpt method redhcp
[Router–GigabitEthernet3/1/2] quit
Configuring cross-subnet portal authentication
Network requirements
As shown in Figure 6:
· Router A is configured for cross-subnet portal authentication. Before portal authentication, users can access only the portal server. After passing portal authentication, they can access Internet resources.
· A RADIUS server serves as the authentication/accounting server.
Configuration procedure
|
NOTE: · Make sure that the IP address of the portal device added on the portal server is the IP address of the interface connecting users (20.20.20.1 in this example), and the IP address group associated with the portal device is the network segment where the users reside (8.8.8.0/24 in this example). · Configure IP addresses for the host, routers, and servers as shown in Figure 6 and make sure that they can reach each other. · Configure the RADIUS server properly to provide normal authentication/accounting functions for users. |
Configure Router A:
1. Configure a RADIUS scheme
# Create a RADIUS scheme named rs1 and enter its view.
<RouterA> system-view
[RouterA] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the CAMS or iMC server, set the server type to extended.
[RouterA-radius-rs1] server-type extended
# Configure the primary authentication server, the primary accounting server, and the keys for the servers to communicate.
[RouterA-radius-rs1] primary authentication 192.168.0.112
[RouterA-radius-rs1] primary accounting 192.168.0.112
[RouterA-radius-rs1] key authentication radius
[RouterA-radius-rs1] key accounting radius
# Specify that the ISP domain name should not be included in the username sent to the RADIUS server.
[RouterA-radius-rs1] user-name-format without-domain
[RouterA-radius-rs1] quit
2. Configure an authentication domain
# Create an ISP domain named dm1 and enter its view.
[RouterA] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[RouterA-isp-dm1] authentication portal radius-scheme rs1
[RouterA-isp-dm1] authorization portal radius-scheme rs1
[RouterA-isp-dm1] accounting portal radius-scheme rs1
[RouterA-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without any ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user.
[RouterA] domain default enable dm1
3. Configure portal authentication
# Configure the portal server as follows:
¡ Name: newpt
¡ IP address: 192.168.0.111
¡ Key: portal
¡ Port number: 50100
¡ URL: http://192.168.0.111:8080/portal.
<RouterA> system-view
[RouterA] portal server newpt ip 192.168.0.111 key portal port 50100 url http://192.168.0.111:8080/portal
# Enable portal authentication on the interface connecting Router B.
[RouterA] interface GigabitEthernet 3/1/2
[RouterA–GigabitEthernet3/1/2] portal server newpt method layer3
[RouterA–GigabitEthernet3/1/2] quit
On Router B, configure a default route to subnet 192.168.0.0/24, setting the next hop as 20.20.20.1. (Details not shown)
Configuring re-DHCP portal authentication with extended functions
Network requirements
As shown in Figure 7:
· The router is configured for re-DHCP extended portal authentication. The host is assigned an IP address through the DHCP server. Before extended portal authentication, the host uses an assigned private IP address. After passing the authentication, the host gets a public IP address.
· When users have passed identity authentication but have not passed security checking, they can access only subnet 192.168.0.0/24. After passing security checking, they can access Internet resources.
· A RADIUS server serves as the authentication/accounting server.
Configuration procedure
|
NOTE: · For re-DHCP portal authentication, 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. (Details not shown) · For re-DHCP portal authentication, the router must be configured as a DHCP relay agent 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). For DHCP configuration information, see Layer 3—IP Services Configuration Guide. · Make sure that the IP address of the portal device added on the portal server is the public IP address of the interface connecting users (20.20.20.1 in this example), the private IP address range for the IP address group associated with the portal device is the private network segment where the users reside (10.0.0.0/24 in this example), and the public IP address range for the IP address group is the public network segment 20.20.20.0/24. · Configure IP addresses for the router and servers as shown in Figure 7 and make sure that the host, router, and servers can reach each other. · Configure the RADIUS server properly to provide normal authentication/accounting functions for users. |
Configure the router:
1. Configure a RADIUS scheme
# Create a RADIUS scheme named rs1 and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the CAMS or iMC server, you need set the server type to extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.
[Router-radius-rs1] primary authentication 192.168.0.113
[Router-radius-rs1] primary accounting 192.168.0.113
[Router-radius-rs1] key authentication radius
[Router-radius-rs1] key accounting radius
# Specify to exclude ISP domain names from the usernames to be sent to the RADIUS server.
[Router-radius-rs1] user-name-format without-domain
# Configure the IP address of the security policy server.
[Router-radius-rs1] security-policy-server 192.168.0.114
[Router-radius-rs1] quit
2. Configure an authentication domain
# Create an ISP domain named dm1 and enter its view.
[Router] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] accounting portal radius-scheme rs1
[Router-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters the username without the ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user.
[Router] domain default enable dm1
3. Configure the ACL (ACL 3000 ) for resources on subnet 192.168.0.0/24 and the ACL (ACL 3001) for Internet resources
|
NOTE: On the security policy server, specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL. |
[Router] acl number 3000
[Router-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[Router-acl-adv-3000] rule deny ip
[Router-acl-adv-3000] quit
[Router] acl number 3001
[Router-acl-adv-3001] rule permit ip
[Router-acl-adv-3001] quit
4. Configure portal authentication
# Configure the portal server as follows:
¡ Name: newpt
¡ IP address: 192.168.0.111
¡ Key: portal
¡ Port number: 50100
¡ URL: http://192.168.0.111:8080/portal.
[Router] portal server newpt ip 192.168.0.111 key portal port 50100 url http://192.168.0.111:8080/portal
# Configure the router as a DHCP relay agent, and enable the IP address match check function.
[Router] dhcp enable
[Router] dhcp relay server-group 0 ip 192.168.0.112
[Router] interface GigabitEthernet 3/1/2
[Router–GigabitEthernet3/1/2] ip address 20.20.20.1 255.255.255.0
[Router–GigabitEthernet3/1/2] ip address 10.0.0.1 255.255.255.0 sub
[Router-GigabitEthernet3/1/2] dhcp select relay
[Router-GigabitEthernet3/1/2] dhcp relay server-select 0
[Router-GigabitEthernet3/1/2] dhcp relay address-check enable
# Enable portal authentication on the interface connecting the host.
[Router–GigabitEthernet3/1/2] portal server newpt method redhcp
[Router–GigabitEthernet3/1/2] quit
Configuring cross-subnet portal authentication with extended functions
Network requirements
As shown in Figure 8:
· Router A is configured for cross-subnet extended portal authentication. When users have passed identity authentication but have not passed security checking, they can access only subnet 192.168.0.0/24. After passing the security checking, they can access Internet resources.
· A RADIUS server serves as the authentication/accounting server.
Configuration procedure
|
NOTE: · Make sure that the IP address of the portal device added on the portal server is the IP address of the interface connecting users (20.20.20.1 in this example), and the IP address group associated with the portal device is the network segment where the users reside (8.8.8.0/24 in this example). · Configure IP addresses for the host, routers, and servers as shown in Figure 8 and make sure that they can reach each other. · Configure the RADIUS server properly to provide normal authentication/accounting functions for users. |
Configure Router A:
1. Configure a RADIUS scheme
# Create a RADIUS scheme named rs1 and enter its view.
<RouterA> system-view
[RouterA] radius scheme rs1
# Set the server type for the RADIUS scheme. When using the CAMS or iMC server, set the server type to extended.
[RouterA-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.
[RouterA-radius-rs1] primary authentication 192.168.0.112
[RouterA-radius-rs1] primary accounting 192.168.0.112
[RouterA-radius-rs1] key accounting radius
[RouterA-radius-rs1] key authentication radius
[RouterA-radius-rs1] user-name-format without-domain
# Configure the IP address of the security policy server.
[RouterA-radius-rs1] security-policy-server 192.168.0.113
[RouterA-radius-rs1] quit
2. Configure an authentication domain
# Create an ISP domain named dm1 and enter its view.
[RouterA] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[RouterA-isp-dm1] authentication portal radius-scheme rs1
[RouterA-isp-dm1] authorization portal radius-scheme rs1
[RouterA-isp-dm1] accounting portal radius-scheme rs1
[RouterA-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without any ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user.
[RouterA] domain default enable dm1
3. Configure the ACL (ACL 3000 ) for resources on subnet 192.168.0.0/24 and the ACL (ACL 3001) for Internet resources
|
NOTE: On the security policy server, specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL. |
[RouterA] acl number 3000
[RouterA-acl-adv-3000] rule permit ip destination 192.168.0.0 0.0.0.255
[RouterA-acl-adv-3000] rule deny ip
[RouterA-acl-adv-3000] quit
[RouterA] acl number 3001
[RouterA-acl-adv-3001] rule permit ip
[RouterA-acl-adv-3001] quit
4. Configure extended portal authentication
# Configure the portal server as follows:
¡ Name: newpt
¡ IP address: 192.168.0.111
¡ Key: portal
¡ Port number: 50100
¡ URL: http://192.168.0.111:8080/portal.
[RouterA] portal server newpt ip 192.168.0.111 key portal port 50100 url http://192.168.0.111:8080/portal
# Enable portal authentication on the interface connecting Router B.
[RouterA] interface GigabitEthernet 3/1/2
[RouterA–GigabitEthernet3/1/2] portal server newpt method layer3
[RouterA–GigabitEthernet3/1/2] quit
On Router B, configure a default route to subnet 192.168.0.0/24, setting the next hop as 20.20.20.1. (Details not shown)
Configuring portal server detection and portal user information synchronization
Network requirements
As shown in Figure 9, a host is connected to the router and must pass portal authentication to access the Internet. A RADIUS server serves as the authentication/accounting server.
Detailed requirements are as follows:
· The host is assigned a public network IP address either manually or through DHCP. Before passing portal authentication, the host can access only the portal server. After passing portal authentication, the host can access the Internet.
· The access device (Router) can detect whether the portal server is reachable and send trap messages upon portal server state changes. When the portal server is unreachable due to, for example, a connection failure, network device failure, or portal server failure, the access device can disable portal authentication, allowing users to access the Internet without authentication.
· The access device can synchronize portal user information with the portal server periodically.
Configuration considerations
1. Configure the portal server and enable portal server heartbeat function and the portal user heartbeat function.
2. Configure the RADIUS server to implement authentication and accounting.
3. Configure cross-subnet portal authentication on interface GigabitEthernet 3/1/2 of the router.
4. Configure the portal server detection function on the router, so that Router can detect the status of the portal server by cooperating with the portal server heartbeat function.
5. Configure the portal user information synchronization function, so that the router can synchronize portal user information with the portal server by cooperating with the portal user heartbeat function.
|
NOTE: · Configure IP addresses for the host, router, and servers as shown in Figure 9 and make sure that they can reach each other. · Configure the RADIUS server properly to provide normal authentication/accounting functions for users. |
Configuring the portal server
|
NOTE: The following example assumes that the portal server runs iMC PLAT 3.20-R2606P P13 and iMC UAM 3.60- E6301. |
# Configure the portal server.
Log on to the iMC management platform and select the Service tab. Then, select Portal Service Management > Server from the navigation tree to enter the portal server configuration page, as shown in Figure 10.
· Configure the portal server heartbeat interval and user heartbeat interval.
· Use the default value for other parameters.
Figure 10 Portal server configuration
# Configure an IP address group.
Select Portal Service Management > IP Group from the navigation tree to enter the portal IP address group configuration page. Then, click Add to enter the page for adding an IP address group, as shown in Figure 11.
· Enter the IP group name.
· Enter the start IP address and end IP address of the IP address group. Make sure that the IP address of the user host is within this IP address group.
· Select a service group. By default, the group Ungrouped is used.
· Select the IP group type Normal.
Figure 11 Adding an IP address group
# Add a portal device.
Select Portal Service Management > Device from the navigation tree to enter the portal device configuration page. Then, click Add to enter the page for adding a portal device, as shown in Figure 12.
· Enter the device name NAS.
· Enter the IP address of the router’s interface connected to the host.
· Enter the key, which must be the same as that configured on the router.
· Specify whether to enable IP address reallocation. This example uses cross-subnet portal authentication, and therefore select No from the Reallocate IP list.
· Set whether to support the portal server heartbeat and user heartbeat functions. In this example, select Yes for both Support Server Heartbeat and Support User Heartbeat..
Figure 12 Adding a portal device
# Associate the portal device with the IP address group.
As shown in Figure 13, on the device list, click the icon in the Port Group Information Management column of device NAS to enter the port group configuration page.
On the port group configuration page, click Add to enter the page for adding a port group, as shown in Figure 14. Perform the following configurations:
· Enter the port group name.
· Select the configured IP address group. The IP address used by a user to access the network must be within this IP address group.
· Use the default settings for other parameters.
# Select Service Parameters > Validate System Configuration from the navigation tree to make the above configurations take effect.
Configuring the router
1. Configure a RADIUS scheme
# Create RADIUS scheme rs1 and enter its view.
<Router> system-view
[Router] radius scheme rs1
# Configure the server type for the RADIUS scheme. When using the iMC server, configure the RADIUS server type as extended.
[Router-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.
[Router-radius-rs1] primary authentication 192.168.0.112
[Router-radius-rs1] primary accounting 192.168.0.112
[Router-radius-rs1] key authentication radius
[Router-radius-rs1] key accounting radius
# Specify to exclude ISP domains from the usernames to be sent to the RADIUS server.
[Router-radius-rs1] user-name-format without-domain
[Router-radius-rs1] quit
2. Configure an authentication domain
# Create ISP domain dm1 and enter its view.
[Router] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[Router-isp-dm1] authentication portal radius-scheme rs1
[Router-isp-dm1] authorization portal radius-scheme rs1
[Router-isp-dm1] accounting portal radius-scheme rs1
[Router-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without any ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user.
[Router] domain default enable dm1
3. Configure portal authentication
# Configure a portal server on the router, making sure that the IP address, port number and URL match those of the actual portal server.
[Router] portal server newpt ip 192.168.0.111 key portal port 50100 url http://192.168.0.111:8080/portal
# Enable portal authentication on the interface connecting the host.
[Router] interface Gigabitethernet 3/1/2
[Router–GigabitEthernet3/1/2] portal server newpt method layer3
[Router–GigabitEthernet3/1/2] quit
4. Configure the portal server detection function
# Configure the access device to detect portal server newpt, specifying the detection method as portal heartbeat probe, setting the server probe interval to 40 seconds, and specifying the access device to send a server unreachable trap message and disable portal authentication to permit unauthenticated portal users if two consecutive probes fail.
[Router] portal server newpt server-detect method portal-heartbeat action trap permit-all interval 40 retry 2
|
NOTE: The product of interval and retry must be greater than or equal to the portal server heartbeat interval, and H3C recommends configuring the interval to be greater than the portal server heartbeat interval configured on the portal server. |
5. Configure portal user information synchronization
# Configure the access device to synchronize portal user information with portal server newpt, setting the synchronization probe interval to 600 seconds, and specifying the access device to log off users if the users do not appear in the user synchronization packets sent from the server within two consecutive probe intervals.
[Router] portal server newpt user-sync interval 600 retry 2
|
NOTE: The product of interval and retry must be greater than or equal to the portal user heartbeat interval, and H3C recommends configuring the interval to be greater than the portal user heartbeat interval configured on the portal server. |
Verifying the configuration
Perform the following command to view information about the portal server.
<Router> display portal server newpt
Portal server:
1)newpt:
IP : 192.168.0.111
Key : portal
Port : 50100
URL : http://192.168.0.111:8080/portal
Status : Up
Cross-subnet portal authentication across VPNs
Network requirements
As shown in Figure 15, Router A, as the PE router connecting the user side, needs to provide cross-subnet portal authentication for hosts in VPN 1 through communication with the RADIUS server and portal server in VPN 3.
Configuration procedure
|
NOTE: · Before enabling portal authentication, be sure to configure the MPLS L3VPN capabilities properly and specify VPN targets for VPN 1 and VPN 3 so that VPN 1 and VPN 3 can communicate with each other. This example gives only the access authentication configuration on the user-side PE. For information about MPLS L3VPN, see MPLS Configuration Guide. · Configure the RADIUS server properly to provide normal authentication/accounting functions for users. |
Configure Router A:
1. Configure a RADIUS scheme
# Create a RADIUS scheme named rs1 and enter its view.
<RouterA> system-view
[RouterA] radius scheme rs1
# Configure the VPN instance to which the RADIUS scheme belongs as vpn3.
[RouterA-radius-rs1] vpn-instance vpn3
# Set the server type for the RADIUS scheme. When using the CAMS or iMC server, set the server type to extended.
[RouterA-radius-rs1] server-type extended
# Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers.
[RouterA-radius-rs1] primary authentication 192.168.0.111
[RouterA-radius-rs1] primary accounting 192.168.0.111
[RouterA-radius-rs1] key accounting radius
[RouterA-radius-rs1] key authentication radius
# Specify to exclude ISP domains from the usernames to be sent to the RADIUS server.
[RouterA-radius-rs1] user-name-format without-domain
# Specify the source IP address for RADIUS packets to be sent as 3.3.0.3.
[RouterA-radius-rs1] nas-ip 3.3.0.3
[RouterA-radius-rs1] quit
|
IMPORTANT: Use the nas-ip command to specify the source IP address for RADIUS packets to be sent, and make sure that the source IP address is consistent with the IP address of the access device specified on the server, so as to avoid authentication failures. |
2. Configure an authentication domain
# Create an ISP domain named dm1 and enter its view.
[RouterA] domain dm1
# Configure the ISP domain to use RADIUS scheme rs1.
[RouterA-isp-dm1] authentication portal radius-scheme rs1
[RouterA-isp-dm1] authorization portal radius-scheme rs1
[RouterA-isp-dm1] accounting portal radius-scheme rs1
[RouterA-isp-dm1] quit
# Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without any ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user.
[RouterA] domain default enable dm1
3. Configure portal authentication
# Configure the portal server as follows:
¡ Name: newpt
¡ IP address: 192.168.0.111
¡ VPN: vpn3
¡ Key: portal
¡ Port number: 50100
¡ URL: http://192.168.0.111:8080/portal.
[RouterA] portal server newpt ip 192.168.0.111 vpn-instance vpn3 key portal port 50100 url http://192.168.0.111:8080/portal
# Enable cross-subnet portal authentication on the interface connecting the user side.
[RouterA] interface Gigabitethernet 3/1/1
[RouterA–GigabitEthernet3/1/1] portal server newpt method layer3
[RouterA–GigabitEthernet3/1/1] quit
Verification
Execute the display portal server command to check whether the portal configuration has taken effect. After Host passes portal authentication, perform the display portal user command to view information about online portal users on Router A.
[RouterA] display portal user all
Index:2
State:ONLINE
SubState:NONE
ACL:NONE
Work-mode:stand-alone
VPN instance:vpn1
MAC IP Vlan Interface
----------------------------------------------------------------------------
000d-88f7-c268 3.3.0.1 0 GigabitEthernet3/1/1
Total 1 user(s) matched, 1 listed.
Troubleshooting portal
Inconsistent keys on the router (access device) and the portal server
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.
Analysis
The key configured on the router and that on the portal server are inconsistent, causing CHAP message exchange failure. As a result, the portal server does not display the authentication page.
Solution
· Use the display portal server command to display the key for the portal server on the router and view the key for the router on the portal server.
· Use the portal server command to modify the key on the router or modify the key on the portal server to make sure that the keys are consistent.
Incorrect server port number on the router (access device)
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 router, but the user can log out by using the disconnect attribute on the authentication client.
Analysis
When you execute the portal delete-user command on the router to force the user to log out, the router 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 router 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 router. The source port is 50100 and the destination port of the ACK_LOGOUT message from the router 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 router. Therefore, the user can log out the portal server.
Solution
Use the display portal server command to display the listening port of the portal server on the router and use the portal server command in the system view to modify it to make sure that it is the actual listening port of the portal server.