HP VPN Firewall Appliances Access Control Configuration Guide

146
No security policy server is needed for local portal service, because the portal system using the local
portal server does not support extended portal functions.
The local portal server function of the access device implements only some simple portal server functions.
It only allows users to log on and log off through the Web interface. It cannot take the place of an
independent portal server.
Protocols used for interaction between the client and local portal server
HTTP or HTTPS can be used for interaction between an authentication client and an access device
providing the local portal server function. If HTTP is used, there are potential security problems because
HTTP packets are transferred in plain text. If HTTPS is used, secure data transmission is ensured because
HTTPS packets are transferred in cipher text based on SSL.
Authentication page customization support
The local portal server function allows you to customize authentication pages. You can customize
authentication pages by editing the corresponding HTML files and then compress and save the files to the
storage medium of the device. A set of customized authentication pages consists of six authentication
pages: the logon page, the logon success page, the online page, the logoff success page, the logon
failure page, and the system busy page. A local portal server pushes a corresponding authentication
page at each authentication phase. If you do not customize the authentication pages, the local portal
server pushes the default authentication pages. For information about authentication page customization
rules, see "Customizing authentication pages."
Portal authentication modes
Portal authentication can work at Layer 2 or Layer 3 of the OSI model. The firewall supports only 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, no Layer 3 forwarding devices exist between the authentication client and the access
device. In cross-subnet authentication, Layer 3 forwarding devices can exist between the authentication
client and the access device.
• Direct authentication
Before authentication, a user manually configures a public IP address or directly obtains a public
IP address through DHCP, and can access only the portal server and predefined free websites.
After passing authentication, the user can access the 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 IP address planning and allocation problem. 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
Cross-subnet authentication is similar to direct authentication, but it allows Layer 3 forwarding
devices to be present between the authentication client and the access device.