HP A 5120 Manual

							 
121 
 NOTE: 
 If the port number of a web proxy server is 80, you do not need to configure the port number of the server on 
the device. 
 If a user’s browser uses the Web Proxy Auto-Discovery (WPAD) protocol to discover web proxy servers, you 
need to add the port numbers of the web proxy servers on the device, and configure portal-free rules to allow 
user packets destined for the IP address of the WPAD server to pass without authentication. 
 For Layer 2 portal authentication, you need to add the port numbers of the web proxy servers on the device and 
users need to ensure that their browsers that use a web proxy server do not use the proxy server for the listening 
IP address of the local portal server. Thus, HTTP packets that the portal user sends to the local portal server will 
not be sent to the web proxy server.  
Enabling support for portal user moving  
 NOTE: 
Only Layer 2 portal authentication supports this feature.  
In  scenarios  where  there  are  hubs,  Layer  2  switches,  or  APs between users  and  the  access  devices,  if  an 
authenticated  user  moves  from the  current  access port  to  another Layer  2-portal-authentication-enabled 
port  of  the  device  without logging  off,  the  user  cannot  get  online  when  the  original  port  is  still  up.  The 
reason  is  that the original  port  is  still  maintaining  the  authentication  information  of  the  user  and  the 
device does not permit such a user to get online from another port by default.  
To solve the problem, enable support for portal user moving on the device. Then, when a user moves from 
a port of the device to another, the device provides services in either of the following two ways: 
 If the original port is still up and the two ports belong to the same VLAN, the device allows the user 
to  continue  to  access the network  without  re-authentication,  and  uses  the  new  port  information  for 
user accounting. 
 If  the  original  port  is  down  or  the  two  ports  belong  to  different  VLANs,  the  device  removes  the 
authentication  information  of  the  user  from  the  original  port  and  authenticates  the  user  on  the  new 
port. 
Follow these steps to enable support for portal user moving: 
To do… Use the command… Remarks 
Enter system view system-view — 
Enable support for portal user 
moving portal move-mode auto Required 
Disabled by default 
 
 NOTE: 
For a user with authorization information (such as authorized VLAN) configured, after the user moves 
from a port to another, the device tries to assign the authorization information to the new port. If the 
operation fails, the device deletes the user’s information from the original port and re-authenticates the 
user on the new port.   
						

							 
122 
Specifying the Auth-Fail VLAN for portal 
authentication 
 
 NOTE: 
Only Layer 2 portal authentication supports this feature.  
You can specify the Auth-Fail VLAN to be assigned to users failing portal authentication. 
Before specifying the Auth-Fail VLAN, be sure to create the VLAN. 
Follow these steps to specify the Auth-Fail VLAN for portal authentication: 
To do… Use the command… Remarks 
Enter system view system-view — 
Enter Layer 2 Ethernet interface 
view 
interface interface-type interface-
number — 
Specify the Auth-Fail VLAN for 
portal authentication on the port 
portal auth-fail vlan authfail-vlan-
id 
Required 
Not specified by default 
 
 NOTE: 
 To make the Auth-Fail VLAN of portal authentication on a port take effect, you also need to enable the MAC-
based VLAN function on the port. For information about MAC VLAN, see the Layer 2—LAN Switching 
Configuration Guide. 
 You can specify different Auth-Fail VLANs for portal authentication on different ports. A port can be specified 
with only one Auth-Fail VLAN for portal authentication. 
 The MAC-VLAN entries generated due to portal authentication failures will not overwrite the MAC-VLAN entries 
already generated in other authentication modes.  
Specifying the auto redirection URL for 
authenticated portal users 
After  a user  passes  portal  authentication,  if  the  access  device  is  configured with  an  auto redirection  URL, 
it redirects the user to the URL after a specified period of time. 
Follow these steps to specify the auto redirection URL for authenticated portal users: 
To do… Use the command… Remarks 
Enter system view system-view — 
Specify the auto redirection URL 
for authenticated portal users 
portal redirect-url url-string [ 
wait-time period ] 
Required 
By default, a user authenticated by 
the local portal server is not 
redirected, while a user authenticated 
by a remote portal server is redirected 
to the URL the user typed in the 
address bar before portal 
authentication. 
  
						

							 
123 
 NOTE: 
The wait-time period keyword and argument combination is effective to only local portal authentication.  
Configuring portal detection functions 
After a Layer 2 portal user gets online, the device starts a detection timer for the user, and checks whether 
the  user’s  MAC  address  entry  has  been  aged  out  or the  user’s  MAC  address  entry  has  been  matched (a 
match  means  a packet has  been  received  from  the  user)  at the  interval.  If  the  device  finds no MAC 
address  entry for  the  user  or receives  no  packets  from  the  user  during  two successive detection  intervals, 
the device considers that the user has gone offline and clears the authentication information of the user. 
Follow these steps to set the Layer 2 portal user detection interval:  
To do… Use the command… Remarks 
Enter system view system-view — 
Enter interface view interface interface-type interface-
number — 
Set the Layer 2 portal user 
detection interval 
portal offline-detect interval 
offline-detect-interval 
Required 
300 seconds by default 
 
Logging off portal users 
Logging off a  user  terminates the  authentication process for  the  user  or removes the  user from  the 
authenticated users list.  
Follow these steps to log off users: 
To do… Use the command… Remarks 
Enter system view system-view — 
Log off users 
portal delete-user { ip-address | 
all | interface interface-type 
interface-number } 
Required 
 
Displaying and maintaining portal 
To do… Use the command… Remarks 
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 specified interface 
display portal interface interface-type 
interface-number [ | { begin | exclude | 
include } regular-expression ] 
Available in any view 
Display configuration information 
about the local portal server 
display portal local-server [ | { begin | 
exclude | include } regular-expression ] Available in any view  
						

							 
124 
To do… Use the command… Remarks 
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 specified interface or 
all interfaces 
display portal user { all | interface 
interface-type interface-number } [ | { 
begin | exclude | include } regular-
expression ] 
Available in any view 
Clear TCP spoofing statistics reset portal tcp-cheat statistics Available in user view 
 
Portal configuration examples 
Configuring Layer 2 portal authentication 
Network requirements 
As  shown  in Figure  43,  a  host  is  directly  connected  to a switch.  The  switch  performs  Layer  2  portal 
authentication on users connected to port GigabitEthernet 1/0/1. More specifically, 
 Use the remote RADIUS server for authentication, authorization and accounting. 
 Use the remote DHCP server to assign IP addresses to users. 
 The listening IP address of the local portal server is 4.4.4.4. The local portal server pushes the user-
defined authentication pages to users and uses HTTPS to transmit authentication data. 
 Add users passing authentication to VLAN 3. 
 Add  users  failing  authentication  to  VLAN  2, to  allow  the  users  to  access  resources  on  the  update 
server. 
 The host obtains an IP address through DHCP. Before authentication, the DHCP server assigns an  IP 
address in  segment 192.168.1.0/24 to the host. When the host passes the  authentication, the DHCP 
server  assigns  an  IP  address in  segment 3.3.3.0/24 to  the  host.  When  the  host  fails  authentication, 
the DHCP server assigns an IP address in segment 2.2.2.0/24 to the host.  
						

							 
125 
Figure 43 Network diagram for Layer 2 portal authentication configuration 
 
 
Configuration procedures 
 
 NOTE: 
 Ensure that the host, switch, and servers can reach each other before portal authentication is enabled. 
 Configure the RADIUS server properly to provide normal authentication/authorization/accounting functions for 
users. In this example, you need to create a portal user account with the account name userpt on the RADIUS 
server, and configure an authorized VLAN for the account. 
 On the DHCP server, you need to specify the IP address ranges (192.168.1.0/24, 3.3.3.0/24, 2.2.2.0/24), 
specify the default gateway addresses (192.168.1.1, 3.3.3.1, 2.2.2.1), specify the device to not assign the update 
server’s address 2.2.2.2 to any host, specify the leases of the assigned IP addresses (set a short lease duration 
for each address to shorten the IP address update time in case of an authentication state change) and make sure 
there is a route to the host. 
 As the DHCP server and the DHCP client are not in the same subnet, you need to configure a DHCP relay agent 
on the subnet of the client. For more information about DHCP relay agent, see the Layer 3—IP Services 
Configuration Guide.  
1. Configure portal authentication 
#  Add  Ethernet  ports  to  related  VLANs  and  configure  IP  addresses  for  the  VLAN  interfaces.  (Details  not 
shown) 
#  Configure  PKI  domain pkidm,  and  apply  for  a  local  certificate  and  CA  certificate.  For  more 
configuration information, see the chapter ―PKI configuration.‖ 
#  Edit  the  user-defined  authentication  pages  file,  compress  it  into  a  zip  file  named defaultfile,  and  save 
the file in the root directory of the access device. 
# Configure SSL server policy sslsvr, and specify to use PKI domain pkidm. 
 system-view 
[Switch] ssl server-policy sslsvr 
[Switch-ssl-server-policy-sslsvr] pki pkidm 
[Switch-ssl-server-policy-sslsvr] quit IP network
RADIUS server
Switch
1.1.1.2/24
Host 
Vlan-int33.3.3.1
Vlan-int8192.168.1.1/24GE1/0/1
Vlan-int11.1.1.1
DHCP server
Update server2.2.2.2/24
1.1.1.3/24
(DHCP relay)
Vlan-int22.2.2.1/24  
						

							 
126 
# Configure the local portal server to support HTTPS and reference SSL server policy sslsvr. 
[Switch] portal local-server https server-policy sslsvr 
# Configure the IP address of loopback interface 12 as 4.4.4.4. 
[Switch] interface loopback 12 
[Switch-LoopBack12] ip address 4.4.4.4 32 
[Switch-LoopBack12] quit 
# Specify  IP  address 4.4.4.4  as  the  listening  IP  address  of  the  local  portal  server  for  Layer  2  portal 
authentication. 
[Switch] portal local-server ip 4.4.4.4 
# Enable portal authentication on port GigabitEthernet 1/0/1, and specify the Auth-Fail VLAN of the port 
as VLAN 2. 
[Switch] interface gigabitethernet 1/0/1 
[Switch–GigabitEthernet1/0/1] port link-type hybrid 
[Switch–GigabitEthernet1/0/1] mac-vlan enable 
[Switch–GigabitEthernet1/0/1] portal local-server enable 
[Switch–GigabitEthernet1/0/1] portal auth-fail vlan 2 
[Switch–GigabitEthernet1/0/1] quit 
2. Configure a RADIUS scheme 
# Create a RADIUS scheme named rs1 and enter its view.  
 system-view 
[Switch] radius scheme rs1 
#  Set  the  server  type for  the  RADIUS  scheme.  When  using  the  iMC  server,  set  the  server  type to 
extended.  
[Switch-radius-rs1] server-type extended 
# Specify the  primary  authentication  server and primary  accounting  server,  and configure the keys  for 
communication with the servers. 
[Switch-radius-rs1] primary authentication 1.1.1.2 
[Switch-radius-rs1] primary accounting 1.1.1.2 
[Switch-radius-rs1] key accounting radius 
[Switch-radius-rs1] key authentication radius 
[Switch-radius-rs1] quit 
3. Configure an authentication domain 
# Create and enter ISP domain triple. 
[Switch] domain triple 
# Configure AAA methods for the ISP domain. 
[Switch-isp-triple] authentication portal radius-scheme rs1 
[Switch-isp-triple] authorization portal radius-scheme rs1 
[Switch-isp-triple] accounting portal radius-scheme rs1 
[Switch-isp-triple] quit 
# Configure triple 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 are  used  for  the 
user. 
[Switch] domain default enable triple 
4. Configure the DHCP relay agent  
						

							 
127 
# Enable DHCP. 
[Switch] dhcp enable 
# Create DHCP server group 1 and add DHCP server 1.1.1.3 into the group. 
[Switch] dhcp relay server-group 1 ip 1.1.1.3 
# Enable the DHCP relay agent on VLAN-interface 8. 
[Switch] interface vlan-interface 8 
[Switch-Vlan-interface8] dhcp select relay 
# Correlate DHCP server group 1 with VLAN-interface 8. 
[Switch-Vlan-interface8] dhcp relay server-select 1 
[Switch-Vlan-interface8] quit 
# Enable the DHCP relay agent on VLAN-interface 2. 
[Switch] interface vlan-interface 2 
[Switch-Vlan-interface2] dhcp select relay 
# Correlate DHCP server group 1 with VLAN-interface 2. 
[Switch-Vlan-interface2] dhcp relay server-select 1 
[Switch-Vlan-interface2] quit 
# Enable the DHCP relay agent on VLAN-interface 3. 
[Switch] interface vlan-interface 3 
[Switch-Vlan-interface3] dhcp select relay 
# Correlate DHCP server group 1 with VLAN-interface 3. 
[Switch-Vlan-interface3] dhcp relay server-select 1 
[Switch-Vlan-interface3] quit 
Verification 
Before  user userpt accesses  a web  page,  the  user  is  in  VLAN  8 (the  initial  VLAN),  and  is  assigned  with 
an IP address on subnet 192.168.1.0/24. When the user access a web page on the external network, the 
web  request  will  be  redirected  to  authentication  page https://4.4.4.4/portal/logon.htm.  After  entering 
the  correct username  and  password,  the  user  can  pass the  authentication.  Then,  the  device  will  move  the 
user  from  VLAN  8  to  VLAN  3,  the  authorized  VLAN.  You  can  use  the display  connection  ucibindex 
command to view the online user information  
 display connection ucibindex 30 
Slot:  1 
Index=30  , Username=userpt@triple 
MAC=0015-e9a6-7cfe 
IP=192.168.1.2 
IPv6=N/A 
Access=PORTAL  ,AuthMethod=PAP 
Port Type=Ethernet,Port Name=GigabitEthernet1/0/1 
Initial VLAN=8, Authorization VLAN=3 
ACL Group=Disable 
User Profile=N/A 
CAR=Disable 
Priority=Disable 
Start=2011-01-26 17:40:02 ,Current=2011-01-26 17:48:21 ,Online=00h08m19s 
 Total 1 connection matched.  
						

							 
128 
Use the display mac-vlan all command to view the generated MAC-VLAN entries, which record the MAC 
addresses passing authentication and the corresponding VLANs. 
[Switch] display mac-vlan all 
  The following MAC VLAN addresses exist: 
  S:Static  D:Dynamic 
  MAC ADDR         MASK             VLAN ID   PRIO   STATE 
  -------------------------------------------------------- 
  0015-e9a6-7cfe   ffff-ffff-ffff   3         0      D 
  Total MAC VLAN address count:1 
If a client fails  authentication, it will  be  added  to  VLAN  2.  Use  the  previously  mentioned  commands  to 
view the assigned IP address and the generated MAC-VLAN entry for the client. 
Troubleshooting portal 
Inconsistent keys on the access device and the portal server 
Symptom 
When  a  user  is  forced  to  access  the  portal  server, the  portal  server  displays a  blank  web  page,  rather 
than the portal authentication page or an error message. 
Analysis 
The keys configured on  the access  device  and  the  portal  server are  inconsistent, causing CHAP message 
exchange failure. As a result, the portal server does not display the authentication page. 
Solution 
 Use the display portal server command to display the key for the portal server on the access device 
and view the key for the access device on the portal server. 
 Use  the portal  server command  to  modify  the  key  on  the  access  device or modify  the  key for the 
access device on the portal server to ensure that the keys are consistent. 
Incorrect server port number on the access device 
Symptom  
After  a  user  passes  the  portal  authentication,  you  cannot  force  the user to log  off by  executing  the portal 
delete-user command  on  the  access  device,  but  the  user  can log  off by  using  the disconnect attribute  on 
the authentication client. 
Analysis 
When  you  execute  the portal delete-user command  on  the  access  device  to  force  the  user  to log  off,  the 
access  device  actively  sends  a  REQ_LOGOUT  message  to  the  portal  server. The  default  listening  port  of 
the  portal  server  is  50100.  However,  if  the  listening  port  configured  on  the  access  device  is  not  50100, 
the  destination  port  of  the  REQ_LOGOUT  message  is  not  the  actual  listening  port  on  the  server,  and the 
portal server cannot receive the REQ_LOGOUT message. As a result, you cannot force the user to log off 
the portal server. 
When  the  user  uses  the disconnect attribute  on  the  client  to log  off,  the  portal  server  actively  sends  a 
REQ_LOGOUT  message  to  the  access  device.  The  source  port  is  50100  and  the  destination  port  of  the 
ACK_LOGOUT message from the access device is the source port of the REQ_LOGOUT message  so that  
						

							 
129 
the portal server can receive the ACK_LOGOUT message correctly, no matter whether the listening port is 
configured on the access device. The user can log off the portal server. 
Solution 
Use the display portal server command to display the listening port of the portal server configured on the 
access  device and  use  the portal  server command  in  the  system  view  to  modify  it  to  ensure  that  it  is  the 
actual listening port of the portal server. 
  
						

							 
130 
Triple authentication configuration 
Triple authentication overview 
The  terminals  in  a  LAN  may  support different authentication  methods.  As  shown  in Figure  44,  a  printer 
supports  only  MAC  authentication,  a  PC  installed  with  the  802.1X  client  supports  802.1X  authentication, 
and the other PC carries out portal authentication. To satisfy the different authentication requirements, the 
port of  the  access  device  which  connects  to  the  terminals  needs  to support all  the  three  types  of 
authentication  and  allow  a  terminal  to  access  the  network  after  the  terminal  passes  one  type  of 
authentication. 
Figure 44 Triple authentication network diagram 
 
 
The  triple authentication  solution  can  satisfy  the  requirements.  It  is  implemented  by  enabling  portal 
authentication,  MAC  authentication,  and  802.1X  authentication  on  a  Layer-2 access port.  A  terminal 
connected to that port can access the network after passing a type of authentication.   
 NOTE: 
For more information about portal authentication, MAC authentication, and 802.1X authentication, see 
the chapters “Portal configuration,” “MAC authentication configuration,” and “802.1X configuration.”  
Triple authentication mechanism 
The three types of authentication enabled on an access port are triggered differently. 
 Upon receiving an ARP or DHCP broadcast packet from a terminal for the first time, the access port 
performs  MAC  authentication  on  the  terminal.  If  the  terminal passes  MAC  authentication,  no  other 
types  of  authentication  will  be  performed  for  it.  If  it  fails,  802.1X  or  portal  authentication  can  be 
triggered.  
 Upon receiving an EAP packet from an 802.1X client or a thirty-party client, the access port performs 
only 802.1X authentication on the terminal.  IP network
802.1X clientWeb userPrinter
802.1X authentication
MAC authentication
Portal authentication
AAA server