Troubleshooting Captive Portal

This section contains troubleshooting tips for the most common problem with captive portal.

Authentication failures

Authentication failures are normally the result of users entering an incorrect username or password. In the case of RADIUS authentication, these can occur because of connectivity problems to the configured RADIUS server(s), or problems on the RADIUS server itself. Check the RADIUS server logs for indications of why access was denied, and ensure the firewall can communicate with the RADIUS server.

For local users, if the option to require the Captive Portal login privilege is enabled, ensure the users have the privilege directly or are members of a group with the privilege.

Portal Page never loads (times out) nor will any other page load

This is most commonly a DNS failure. If the firewall is not used for DNS, and there are no entries under the Allowed IP Address tab (Allowed IP Address) for the DNS servers, then the users cannot contact DNS to resolve a hostname. If they cannot resolve a hostname, then their browser will never even attempt to load a web page, and thus will never be redirected to the portal page.

To resolve this, either use the firewall IP address and the DNS forwarder for client DNS, or add Allowed IP Address entries for the external DNS servers.

Another possible explanation for this is that the firewall rules on the interface with the portal do not allow the users to reach web sites on port 80. Ensure the firewall rules pass out traffic to TCP port 80, and to make sure DNS works, they must also be able to reach the configured DNS servers on TCP and UDP port 53.

HTTPS home page users do not get redirected to the portal page

It is not possible to redirect HTTPS browsing attempts in a way that will work for users securely and without error. It would either not work at all, or give the user a scary SSL certificate warning for a site they usually trust. Direct users to load an HTTP site and then they will be redirected to the portal and receive a login prompt.

Apple devices are unable to load the portal page or login

Certain versions of Safari on iOS do not properly handle the login form for the Captive Portal page. The most common resolution is to disable autofill for forms in Safari on iOS.

In some cases, Apple devices will not automatically prompt for a Captive Portal login or test for its presence if the wireless network uses encryption. In these cases, manually open a browser and navigate to an HTTP site to get the login redirect.

There have also been reports that on older version of OS X, a Mac would refuse to load any HTTPS sites, including an HTTPS portal, until it could load a CRL and OSCP URL for the certificate. This has been fixed in current versions of OS X.

Some users have had to add www.apple.com to their allowed hostnames so that Apple’s call to their test page succeeds.

Port forwards to hosts behind the portal only work when the target system is logged in

This is a side effect of how the portal operates. No traffic is allowed to reach a host behind the portal unless it has been authenticated or passed through the portal. If a port forward must always work to a device behind the portal, then it must be setup to bypass the portal with either a Pass-through MAC entry (MAC Address Control) or an Allowed IP Address entry (Allowed IP Address) to allow traffic To the target.