Preventing too many browser redirects during guest access
Have you ever seen this issue when you are setting up a guest network with the captive portal page is external to your WLAN controller or AP. Your visitor connects their laptop or smartphone to the guest network, the browser gets redirected but then you see in the URL bar the address flicking between the WLAN controller and the external captive portal server. Often this will end in a browser error message about too many redirects.
This is an issue that network engineers often face when initially setting up their guest network and it is due to the default firewall rules in place for an unauthenticated user. Typically your WLAN infrastructure will have a concept of an 'initial role' or a 'pre-authentication role' that a user connecting to the guest network is associated with until their successfully authenticate. The default firewall rules on many WLAN controllers don't have knowledge of the redirect to the external captive portal so the controller's own attempt to redirect the guest device gets caught in a loop and gets redirected a second, third time and so on until the browser gives up.
The solution to this is to allow the redirect traffic in these initial or pre-authenticated roles. Typically the traffic of interest with been either HTTP or HTTPS depending on the security policy implemented on the guest network.
The following is an example of creating a pre-authentication ACL on a Cisco WLC. Note that the ACL's are stateless and therefore you need to permit the traffic in both directions. The example assumes your external captive portal is on IP address 10.162.110.30 and both HTTP and HTTPS are being permitted.
You then apply this pre-authentication ACL on your WLAN definition for the guest network. Looking at the Layer 3 Web Authentication policy, you can see an option to apply the pre-authentication ACL.
Another example here is from an ArubaOS controller. The ArubaOS allows the network engineer to define an alias for the external captive portal server(s) and this makes it easy to reference them in any future firewall policies.
This is an example of a new firewall policy design to permit both HTTP and HTTPS traffic to your external captive portal server.
You can then simply apply this to the initial role assigned to unauthenticated guest users. In this example that initial role is called guest-logon.