aruba排错

Product and Software: This article applies to all Aruba controllers and ArubaOS 2.5 and later. In this discussion, it is assumed that the Aruba controller has a Policy Enforcement Firewall (PEF) license installed, and that the Captive Portal is configured correctly on the controller. In Aruba OS 2.5, the captiveportal session ACL should be part of the initial role (logon by default). In Aruba OS 3.x, we add another requirement where a Captive Portal profile is selected under the initial role (logon by default). At the wifi client side, it is important to keep in mind that: Captive Portal == Layer 3 IP operation That means that the wireless client should get an IP address, subnet mask, a Gateway, and a DNS address upon wireless association to the Captive Portal SSID. If not, then the client issue with Captive Portal becomes a DHCP issue and should be troubleshooted that way. We will assume in this article that the wifi client does indeed get its IP information upon association to the Captive Portal SSID. For a better understanding of the troubleshooting process, let us review the different operations that a wifi client goes through after it gets an IP address until the Captive Portal login page is displayed: 1. The user enters a web site name in his browser.  2. The client device resolves this name to an IP address.  3. The client starts opening a TCP session to this host IP.  4. The Aruba switch performs dst-nat on this session to redirect it to its msswitch address on port 8080. (This step implies that the policies that are applied to the user are properly set.)  5. Aruba sends a web page that includes an HTML redirection to  https:// <name of the certificate currently installed on the switch>. By default it is https://securelogin.arubanetworks.com .  6. The client issues a DNS lookup for this name.  7. The Aruba switch intercepts this DNS lookup and returns its msswitch IP address (or if configured, to the address specified under 'ip cp-redirect-address').  8. The client opens a TCP session with this address and displays the Captive Portal Login page. The following troubleshooting steps are provided in two cases. 1. Without Web Proxy 1. Associate to the SSID.  2. Open a DOS window. 3. Issue the 'ipconfig /all' command and make sure that: - You have a default gateway correctly defined. This default gateway should be in most cases the Aruba switch. - You have a DNS server configured. It will not work if this is not set in your PC. If you do not have a real DNS server (that is, lab environment), put in a dummy IP address. 3. Issue the 'telnet <dummy IP address (take 1.1.1.1 for example)> 80' command. If a black screen appears, the client could successfully open a TCP conversation. In this case, go to next step. If nothing happens except a connection timeout, the switch does not intercept the HTTP request. The root cause could be one the following reasons: - The role does not contain the needed redirection policy: 'user any svc-http dst-nat 8080' This could be either because the user has already identified himself or simply because default role (usually logon) does not contain the captiveportal policy. By default, it is: user mswitch svc-https dst-nat user any svc-http dst-nat 8080 user any svc-https dst-nat 8081 - The PC has no IP connectivity to the switch. Make sure ping is allowed for the role and try to ping the msswitch IP address. (Or if it is configured, try to ping the address specified under "ip cp-redirect-address". In that case, you must change the first line of the captiveportal policy to allow HTTPS flow to this IP address instead of the msswitch IP.) - The default gateway on the client is not correct. 4. Issue this exact command (case and spaces do matter): "GET / HTTP/1.0"+RETURN A couple of lines should display. Depending on the protocol chosen for doing Captive Portal auth, a link starting with http or https (default) should be displayed. 5. Under the command line, issue 'nslookup <host name contained in the previous link>'. In most of the cases the host name should be "securelogin.arubanetworks.com". If there is no answer, it means your DNS request is not being intercepted by the Aruba switch. The root cause is probably you do not have a DNS configured on your PC or that DNS request does not use the wireless interface. 6. Open a web browser and paste the entire link that you have obtained in the previous step. If it does not work, the probable cause is that the captiveportal policy that you are using in your role does not match the settings that you have defined in Configuration->Security-> Authentification Method->Captive Portal->Protocol Type (same command as 'aaa captive-portal'). In that case, you need either to revert back to HTTPS or change thecaptiveportal policy to: user mswitch svc-http dst-nat user any svc-http dst-nat 8080 user any svc-https dst-nat 8081  2. With Web Proxy If the client is configured to use a proxy on port, redirect this port to port 8088. This redirection is accomplished by modifying the captiveportal policy as follows (example with proxy port 3128): user mswitch svc-http dst-nat user any tcp 3128 dst-nat 8088 user any svc-http dst-nat 8080 user any svc-https dst-nat 8081 Also, remember that if the web client proxy configuration is being distributed via a proxy script (a .pac file), make sure that the 'captiveportal' firewall rule would allow the client to download that file or else the client behaviour will be unpredictable.  Add the following line in the 'captiveportal' rule, before the two dst-nat rules:  user host <IP address of proxy> svc-http permit  The following flowchart summarizes the troubleshooting process.

回复