Web Authentication (Cisco Wireless LAN Controllers) Part 2

Troubleshooting Basic Web Authentication

Understanding how web auth works is key to troubleshooting it when it does not work. Common network issues that have nothing to do with wireless can stop web auth from working. The easiest way to test the guest WLAN is to remove the web auth security setting and see if the client can access the Internet. If it cannot, a network issue is likely to blame. You can also try performing an nslookup from the client or using the IP instead of the web address to see if the client gets the redirect page. If the DNS lookup fails but using the IP address works, the DNS is an issue. To verify that the redirect page on the controller is working, you can also enter https://1.1.1.1/login.html assuming that the IP of the virtual interface on the controller is 1.1.1.1.

The following is a list of common problems that can break web authentication:

■ The guest VLAN is not allowed on the controller trunk port.

■ The guest VLAN is not routed on the network.

■ DNS is blocked by a firewall or network ACLs.

■ The client is configured to use a proxy server. You might be able to make web auth work in conjunction with a network proxy server by performing the following two actions:

1. Add an exception to the client proxy configuration in the browser for the virtual interface IP address of the controller. The user must be a local admin to make this change. Keep in mind that corporate policies might not allow a user to change proxy settings.

2. Use the following command to add the proxy port (in this case port 8080) to the web auth redirect from the controller CLI:

You must save and reboot for this to take effect. The output of the show network summary command will confirm the configuration:

 

 

 

 

■ The client browser does not, allow redirects. From Internet Explorer, Tools > Internet Options > Security > Custom > Allow META-Refresh should be enabled.

■ There is no DHCP on the guest VLAN.

■ The client home page is HTTPS; HTTPS is not currently supported with web auth for the redirect. Hopefully this limitation will be removed in a future code release.

■ A 2000 or 2100 series controller and external web authentication are used, but pre-auth ACL is missing or incorrect.

Debug information can be useful in determining where the redirect issue might lie if you have verified the underlying network configuration. The debug output is more informative with newer controller codes. Using these debugs, you can see the policy manager state of the client, whether the client received an IP address, the redirect, and so on. The most useful debugs for web auth are as follows:

■ debug mac addr client-MAC-address Filters he output of other debugs based on the client MAC address.

■ debug aaa all enable: Debugs authentication.

■ debug pem state enable: Debugs policy manager State Machine.

■ debug pem events enable: Debugs policy manager events.

■ debug dhcp message enable: Debugs DHCP messages.

■ debug dhcp packet enable: Debugs DHCP packets.

■ debug pm ssh-appgw enable: Debugs application gateways.

■ debug pm ssh-tcp enable: Debugs policy manager TCP handling.

Example 14-1 provides sample debug output of a successful web auth process using web authentication to the local user database or the controller.

Example 14-1 Successful Web Authentication Debug Output

 

 

 

 

Example 14-1 Success Web Authentication Debug

 

 

 

 

Example 14-1 Success Web Authentication Debug

 

 

 

 

Tip When you upgrade controller code to 4.2.173.0 or higher, SSLv2 might become disabled and SSLv3 is only accepted by the controller for both web auth and administrative access. You can see if SSLv2 is enabled using the command show network summary. Some Internet browsers—Microsoft Internet Explorer 6 in particular—need to be configured to support SSLv3 because they may not by default. In this case, an IE 6 client, for example, will receive a "404 Page cannot be displayed" message, whereas another browser such as Firefox will work with no issues. If you run into this issue, you can enable SSLv2 on the controller from the CLI using the following command, saving, and rebooting: config network secureweb cipher-option sslv2 enable