Portal Authentication Mode - HP 12500 Series Configuration Manual

On the authentication homepage/authentication dialog box, the user enters and submits the
2.
authentication information, which the portal server then transfers to the access device.
Upon receipt of the authentication information, the access device communicates with the
3.
authentication/accounting server for authentication and accounting.
After successful authentication, the access device checks whether there is a corresponding security
4.
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.
Portal authentication supports NAT traversal, whether it is initiated by a Web client or an iNode. 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, HP 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 iNode client.

Portal authentication mode

The switch 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 direct authentication,
re-DHCP authentication, or cross-subnet authentication. In direct authentication and re-DHCP
authentication mode, no Layer 3 forwarding devices exist between the authentication client and the
access device. In cross-subnet authentication mode, Layer 3 forwarding devices may exist between the
authentication client and the access device.
Direct authentication
Before authentication, a user manually configures a public IP address or 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 network resources. The process of direct authentication is simpler
than that of re-DHCP authentication.
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 problem about IP address planning and allocation and proves to be useful.
For example, a service provider can allocate public IP addresses to broadband users only when they
access networks beyond the residential community network.
IPv6 portal authentication does not support the re-DHCP authentication mode.
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.
105