Guest CWA Portal Behind a Load Balancer
Summit Conference Center hosts 600 attendees per day on a guest SSID. Cisco ISE 3.1 guest services use a self-registration CWA portal with sponsor approval; sponsors receive email approval links, and guests receive SMS credentials. Two PSNs sit behind an F5 load balancer with a wildcard certificate for *.summitconf.example. The guest VLAN has no route to the internet until authorization, and DNS for the portal resolves to the VIP. Symptoms: guests are redirected to the portal, but after submitting the form they see 'Portal not reachable'; sponsor approval links return 'invalid request'; and some Android devices loop between the guest portal and the redirect URL. The load balancer health check targets the PSN management interface. Sponsor emails are delayed by 20 minutes.
1. Trace the CWA flow and explain why guests see 'Portal not reachable' after submitting the form.
Read the worked answer
CWA works in this order: the guest associates, the WLC or switch redirects HTTP to the ISE guest portal, ISE presents the portal, the guest registers, and ISE sends a CoA to apply the authorization profile.
'Portal not reachable' after submit usually means the post-submit redirect or the portal's own URL is not resolvable from the guest VLAN. Check:
- DNS from the guest VLAN for the portal FQDN, not just from the corporate network.
- The wildcard certificate must match the FQDN in the redirect and be trusted by the guest device.
- The F5 virtual server must pass the ISE portal port and preserve the Host header; if it rewrites the host, the certificate and redirect mismatch.
- The load balancer pool must contain both PSNs with a health check against the guest portal service, not the management interface. A management-interface check can mark a healthy portal PSN down.
- The guest VLAN ACL must allow DNS and DHCP before authentication, and allow the portal subnet or VIP.
If the form submits but the success page fails, the issue is often the redirect URL or certificate, not RADIUS.
2. Why do sponsor approval links return 'invalid request', and what should you check in the guest and sponsor portal settings?
Read the worked answer
Sponsor approval links contain a token tied to the portal FQDN and the guest record. 'Invalid request' usually means the link was generated with a different hostname than the one the sponsor uses, the token expired, or the request was already consumed.
Check:
- The guest portal and sponsor portal URL settings both use the load balancer FQDN, not a PSN hostname.
- The certificate SAN includes that FQDN.
- The sponsor approval timeout is long enough for the conference schedule.
- The link was not clicked twice; some tokens are single-use.
- The sponsoring account has the correct sponsor group and approval privilege.
- The guest record still exists and has not been purged.
A common mismatch is generating links on psn1.summitconf.example behind the load balancer but presenting them to sponsors as guest.summitconf.example. Standardize all URLs on the VIP FQDN, then regenerate a test guest and approval link.
3. Why do some Android devices loop between the portal and the redirect URL, and how do you isolate the cause?
Read the worked answer
Android's captive portal detection expects a specific redirect behavior and a trusted certificate. A loop usually means the device is being redirected before it can complete the portal transaction, or the portal certificate is untrusted.
Isolate it by checking:
- The WLC redirect ACL and any 'sleep guest' or pre-authentication ACL that may block the portal's DNS or HTTPS.
- The certificate chain presented by the F5 and the PSNs; Android rejects self-signed or incomplete chains.
- Whether the F5 terminates TLS and re-encrypts; the guest must see a certificate matching the FQDN.
- The ISE authorization profile's redirect URL and the guest portal's default URL.
- DNS resolution from the guest VLAN; if the portal resolves to an unreachable VIP, Android retries in a loop.
Capture traffic on the guest VLAN and compare a working laptop with a looping Android. If the laptop works, the difference is usually certificate trust or captive-portal detection behavior, not the ISE policy itself.