Home > User Interface > Configuration > Advanced Access Configuration > Captive Portal

Captive Portal

Menu path: Configuration > Advanced Access Configuration Overview > Captive Portal.

This page has settings related to network connectivity checks that occurs at the end of a completed authentication as well as CWP operation. Network connectivity checks attempt to connect to a remote web server to ensure network configuration following an authentication.

The field on this page are:

Field	Usage	Example
Network Detection	If enabled, the automatic detection feature is active.
Network Detection IP Address	This IP address is used as the web server who hosts the Detection Image Path file to detect if network access was enabled. Network detection failures can be due to local firewall settings; network access can still be enabled.	34.253.190.240
Detection Image Path	The page on the web server specified in the IP parameter where a GIF or web page is located.	/common/network-access-detection.gif
Initial Delay	The amount of time before network connectivity detection is started after client registration.	5 seconds
Retry Delay	If a network connectivity check fails, the amount of time between checks.	2 seconds
Redirection Delay	The amount of time to display the progress bar that is displayed during network connectivity testing.	20 seconds
Request Timeout	The number of seconds before a request times out in the captive portal.	15
IP Addresses of Load Balancers	A comma-separated list of IP address of any load balancers that exist between clients and the CWP. See further notes in Load Balancers.	10.150.1.63,10.150.1.64
Secure Redirect	If enabled, causes the captive portal to use https:// for all portal clients. If this setting is changed, restart the haproxy-portal service using button at the bottom of the page.
Status URL Only on Production Network	If enabled, the /status page will only be available on production networks. This allows users to self-register a device when device registration is enabled.
Bypass Captive Portal Detection Mechanism	If enabled, the client device's built-in CWP detection logic is bypassed by allowing the listed DNS and HTTP request to pass through to the real hosts instead of being intercepted by A3. The list is specified in the Captive Portal Detection Mechanism URLs field.
Captive Portal Detection Mechanism URLs	A comma-separated list of URLs known to be used by devices to check network connectivity. This list is automatically augmented by all of the elements of the Built-in Captive Portal Detection Mechanism URLs list.
WISPr Redirection Capabilities	If enabled, detects WISPr-based redirection to trigger the captive portal.
Rate Limiting	If enabled, clients that perform more captive portal or invalid URL requests specified in the Rate Limiting Threshold parameter will temporarily be denied access. If this setting is changed, restart the haproxy-portal service using the button on the bottom of the page.
Rate Limiting Threshold	The number of captive portal or invalid URL requests that will trigger rate limiting.	48
Other Domain Names	A comma-specified list of domain names, other than that specified in System Configuration > Main Configuration, which when accessed by a client will be redirected to the CWP.	signup.example.com

Note

When advised to restart any A3 service, the administrative interface for each cluster member must be used individually to perform the operation. Perform the operation on each member one at a time, waiting for the service(s) to completely restart.

Load balancers that operate at layer 7 effectively perform reverse proxying. If the captive portal is located behind load balancers, then the captive portal no longer sees the IP of the node trying to access the portal. In that case, the load balancers must perform SSL offloading and add a X-Forwarded-By header in the HTTP traffic they forward to A3. Most load balancers do this by default and the IP parameter should be set to the IP addresses of the load balancers. This will instruct the captive portal to look for client IPs in the X-Forwarded-For instead of the actual TCP session when it matches an IP in the list.

Note

NOTE: The Apache access log format is not changed to automatically log the X-Forwarded-By header.