Okay. I think is a misunderstanding of terms and what the end goal is. I will briefly outline some of those options and you can confirm your specific scenario.
- Redirect to portal based on direct access to FQDN (Sponsor/MyDevices/Cert/Provisioning Portal): This is the FQDN where Sponsor or other admin connects to manage guests, devices, certs, etc.
- URL after login (outside of guest flow): It is possible to redirect users outside of a guest flow to a landing page as an authorization. This is the option to manually configure cisco-av-pairs for url-redirect-acl and url-redirect to send user to some external page on login. Note: This is a permanent redirect.
- URL after login (inside guest flow): This is option inside Guest Auth Success page settings to send user to their original URL or to specified landing page. Note: This is a one-time redirect (like WLC splash page option).
You did cite Guest Success, so I think I diverged thinking issue was specific to #1 or #2 above. More specific to #3 use case, I would make sure that client is resolved to proper IP on the final landing page per the configured FQDN. Another case which I have found can be problematic is the ACL applied to connection. There is a transition from restricted communication with the PSN and then directive to connect to external server. It may be a timing issue where you get the redirect at client, but authorization has not been processed by the access switch/controller. In this case, if new policy to allow access to external site has not yet been granted, that may cause client access to external page to be redirected based on original authorization.
One way to troubleshoot would be to monitor the client session policy on switch/NAD when the redirect occurs. If new access policy is not in place, then client may get redirected before being granted access. To confirm, if redirected back to original guest login page, 1) verify access policy on NAD and 2) try to manually navigate to the external page to see if it properly displays.
Fixing a race condition may be difficult. TAC may be able to help, but make sure DNS is rock solid. Also, you could consider adding access to the landing page in the initial redirect policy. If users are likely to set that as their home page, and thus bypass initial redirection, you could create a unique FQDN for the landing page which is allowed using DNS ACL. The actual web page could then be configured to redirect the unique FQDN to the common redirect page (to avoid users from bookmarking unique URL). Hope that makes sense.
