R3721-F3210-F3171-HP High-End Firewalls Access Control Configuration Guide-6PW101

114
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 HP iNode.
When the portal authentication client is on a private network, but the portal server is on a public networ
k
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 using an interface's
public IP address 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 HP iNode client.
Portal authentication mode
The firewall (as an access device) supports Layer 3 portal authentication.
You can enable portal authentication on an access device's Layer 3 interfaces connected to the
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 may 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 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
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.
In direct authentication, 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