10-Security Configuration Guide

HomeSupportResource CenterRoutersH3C SR8800 Router SeriesH3C SR8800 Router SeriesTechnical DocumentsConfigure & DeployConfiguration GuidesH3C SR8800 Configuration Guide-Release3347-6W10310-Security Configuration Guide
04-Portal Configuration
Title Size Download
04-Portal Configuration 469.86 KB

Contents

Configuring portal authentication· 1

Portal authentication overview·· 1

Extended portal functions 1

Portal system components 1

Portal authentication modes 3

Portal authentication process 4

Portal authentication across VPNs 5

Portal configuration task list 6

Basic portal configuration· 7

Configuration prerequisites 7

Specifying a portal server for portal authentication· 7

Enabling portal authentication· 8

Controlling access of portal users 9

Configuring a portal-free rule· 9

Configuring an authentication subnet 9

Setting the maximum number of online portal users 10

Specifying an authentication domain for portal users 10

Configuring RADIUS related attributes 11

Specifying NAS-Port-Type for an interface· 11

Specifying a NAS ID profile for an interface· 11

Specifying a source IP address for outgoing portal packets 12

Configuring portal detection functions 13

Configuring the portal server detection function· 13

Configuring portal user information synchronization· 14

Logging out portal users 15

Displaying and maintaining portal 15

Portal configuration examples 16

Configuring re-DHCP portal authentication· 16

Configuring cross-subnet portal authentication· 18

Configuring re-DHCP portal authentication with extended functions 20

Configuring cross-subnet portal authentication with extended functions 23

Configuring portal server detection and portal user information synchronization· 25

Cross-subnet portal authentication across VPNs 30

Troubleshooting portal 32

Inconsistent keys on the router (access device) and the portal server 32

Incorrect server port number on the router (access device) 32

 


Configuring portal authentication

Portal authentication overview

Portal authentication helps control access to the Internet. It is also called “web authentication.” A website implementing portal authentication is called a portal website.

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

Basic portal configuration

Required

Controlling access of portal users

Configuring a portal-free rule

Optional

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

Optional

Specifying a NAS ID profile for an interface

Specifying a source IP address for outgoing portal packets

Optional

Configuring portal detection functions

Configuring the portal server detection function

Optional

Configuring portal user information synchronization

Logging out portal users

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

 

 

NOTE:

·     For installation and configuration about the security policy server, see CAMS EAD Security Policy Component User Manual.

·     The ACL for resources in the quarantined area and that for restricted resources correspond to isolation ACL and security ACL on the security policy server respectively.

·     You can modify the authorized ACL on the router. However, the new ACL takes effect only for portal users logging on after the modification.

 

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 routerinformation for users who are considered nonexistent on the portal serverthe 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.

Figure 5 Network diagram

 

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.

Figure 6 Network diagram

 

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.

Figure 7 Network diagram

 

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.

Figure 8 Network diagram

 

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.

Figure 9 Network diagram

 

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.

Figure 13 Device list

 

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.

Figure 14 Add a port group

 

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

Figure 15 Network diagram

 

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

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.