8.8 Notes on Using Web authentication

(1) Coexistence with other functions

For details about coexistence with other functions, see 5.2 Compatibility between Layer 2 authentication and other functions.

(2) Devices connected between the Switch and terminals subject to authentication

Do not connect a proxy server, router, or similar piece of equipment to the Switch.

If the terminal undergoing authentication is behind a device (such as a proxy server or router) that substitutes its own MAC address in outgoing packets, the Switch will identify the MAC address of the device as belonging to the terminal. This results in an inability to control authentication at the level of individual terminals.

Exercise caution when connecting a hub without inter-port isolation functionality or a wireless LAN downstream from the Switch. PCs attached to that hub or wireless LAN will be able to communicate with each other regardless of their authentication status.

(3) Compatibility with OAN

Web authentication can coexist with OAN. However, the following conditions apply when using Web authentication and OAN together in fixed VLAN mode and dynamic VLAN mode:

• If you connect the AX-Config-Master tool to an authentication port of the Switch and wish to manage the switch without going through Web authentication, you must use the web-authentication web-port configuration command to specify the HTTPS ports used by OAN (ports 832 and 9698).

• If the AX-Config-Master tool is connected to an authentication port of the Switch and you want the tool to manage devices outside the Switch without going through Web authentication, you must configure the access list to forward IP packets used by OAN as shown in the figure below.

  Figure 8-23: Coexistence with OAN

(4) Operation when VLAN function is restarted

When you use the restart vlan operation command to restart the VLAN function, the switch does not clear the authentication status of Web-authenticated users. Instead, users are re-registered in the same order in which they performed authentication. Note that affected users will be unable to access the network until the registration process is complete, which can take some time depending on the number of users.

(5) When Web authenticator restarts

If you restart the Web authentication daemon, the switch cancels the authentication status of all authenticated users. In this case, users need to perform re-authentication manually after the daemon restarts.

(6) About IP address lease time setting of DHCP servers

When using a DHCP server to distribute pre-authentication IP addresses to terminals seeking authentication, specify as short a lease time as possible for IP addresses assigned by the DHCP server.

The smallest lease time the internal DHCP server of the Switch allows is 10 seconds. However, specifying such a small value in an environment with a large number of users can place a heavy load on the switch. Consider this factor when setting the lease time.

(7) Post-Authentication VLAN During Re-Authentication in Legacy Mode

In legacy mode, if a user performs a successful login operation (re-authentication operation) from an authenticated terminal using the ID of an authenticated user, the user does not change VLAN membership even if the VLAN ID returned by the RADIUS server or set in the internal Web authentication DB has changed in the interim.

For local authentication and RADIUS authentication, the same condition applies in that the user remains attached to the post-authentication VLAN assigned at the first successful authentication.