Security

Hi everyone,

I'm facing an intermittent issue with the captive portal on our guest Wi-Fi and would appreciate some guidance or hints on what to check next.

Environment (high level):

• Aruba WLAN (controller-based)
• Guest SSID with captive portal
• Authentication/portal using ClearPass Guest
• Devices affected: Android, iOS and Windows laptops
• Issue happens specifically with new devices coming from outside the environment (first time connection, no previous session/cookie)

Problem description

Users that arrive from outside (visitors) connect to the guest SSID, but do not always get redirected to the captive portal.

The behavior is intermittent:

• Sometimes the captive portal pops up automatically as expected and the user can authenticate and browse normally.
• Other times, for the same SSID and similar devices (Android/iOS/Windows), the user gets connected to Wi-Fi, but no portal is presented (even when opening a browser and trying to access an HTTP site).
• After a while, or after disconnect/reconnect, it may start working again – so it's not a constant failure, it's on and off.

This is affecting only the guest network. Internal/corporate SSIDs are working fine.

Questions / what I'm trying to understand

I'm trying to understand what could cause this behavior to be intermittent for new devices:

1. DHCP / IP assignment
   
• The client gets an IP address from the guest VLAN, but could a DHCP delay or lease exhaustion cause the portal to behave inconsistently?
• Has anyone seen cases where the client gets IP, but because of some DHCP/relay issue the redirect sometimes fails?
2. DNS resolution before authentication
   
• Can misconfigured or intermittent DNS on the pre-auth role cause the portal to show only sometimes?
• For example, if DNS is reachable only part of the time, would that explain why sometimes the OS captive-network detection works and sometimes it doesn't?
3. User role / pre-auth ACL / redirect configuration
   
• If the pre-authentication role or ACL that allows HTTP/HTTPS to ClearPass is misconfigured, could that manifest as "works sometimes, fails sometimes"?
• Any specific rules that you recommend double-checking on the controller/gateway for guest captive portal?
4. OS captive portal detection
   
• On Android, iOS and Windows, captive portal detection is sometimes sensitive to HTTPS/HTTP responses.
• Are there any known best practices/requirements on Aruba + ClearPass side to make this more reliable, especially for new devices?
5. Other common pitfalls
   
• Any known issues with multiple DNS servers, IPv6 enabled on the client, or firewall rules between guest VLAN and ClearPass that could cause this intermittent behavior?

What I'm looking for

• Checklist or best practices for troubleshooting intermittent captive portal issues on Aruba + ClearPass Guest.
• Suggestions on which logs to focus on (controller side, ClearPass Access Tracker, browser/OS level).
• Any real-world experiences of similar behavior with guest SSIDs where new external clients don't consistently receive the portal.

Thanks in advance for any insight or examples you can share.

-------------------------------------------

1. No, unless the pool is indeed empty. Is it?
2. Yes, is DNS allowed? What exactly is in the pre-auth role?
3. Same as 2.
4. No. This should just work. try using neverssl.com once the client is connected.
5. No.

-------------------------------------------

Hi, you have asked the right questions. All of the points you listed are potential sources of error.
However, it is important to understand how Aruba Guest WLAN works. There are several steps involved, some of which are handled by the WLAN controller, some by the ClearPass server, and some by the guest device.
1. The guest device associates with the guest SSID. Here, ClearPass must decide, based on the ruleset, whether MAC address caching is still active or not. When MAC address caching is active, ClearPass must send the post-authenticated Aruba-User-Role (usually called "something-guest-auth"). If MAC address caching is no longer active, the guest device must be assigned the pre-authenticated Aruba-User-Role (usually called "something-guest-logon"). In this case, ClearPass can send an Accept and the pre-authenticated Aruba user role. Alternatively, ClearPass can send a Reject, in which case the guest device remains in the initial-role. This role is specified in the AAA profile used in the VAP profile for the guest WLAN. If ClearPass sends a non-existent or misspelled Aruba-User-Role name, the user always remains in the initial role.

The first step is to check whether the user has been assigned the correct Aruba user role.

2. The guest device receives an IP address via DHCP. It needs a DNS server that can resolve the ClearPass FQDN from the redirect URL. It does not matter whether the DHCP server is accessible directly or via a relay.

Here, you must check whether the guest device has received an IP address and can resolve the ClearPass FQDN.

3. The next step is for the guest device to send an HTTP request. Many clients perform captive portal detection and open a browser, but older clients do not (e.g., Windows 7). With older clients, the browser must be opened manually, which then triggers captive portal detection.  In the worst case, any website must be opened in the browser. This behavior cannot be manipulated by WLAN Controller or ClearPass, it is the responsibility of the OS and the browser.

4. Now it's time for the WLAN controller.
The controller interrupts any HTTP traffic coming from the client and responds with an HTTP 302 message (the requested resource has been temporarily moved to the URL in the Location header). The login-page URL from the captive portal is specified as the destination.

Here you need to check whether the controller can reach the guest device-the routes must be there and firewalls must allow the traffic through. For example, we always configure an IP address in the guest VLAN for each controller. Then the HTTP redirect is not blocked by any firewall.

5. Now it's the client's turn again. Regardless of which URL it tried to access, it must follow the redirect from the HTTP 302 response and open the ClearPass login page.

Here you need to check that DNS resolution is working, the routing is correct, and no firewall is blocking the traffic.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACX - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution
------------------------------