TIP OpenWiFi 2.0
OpenWiFi supports multiple models for Captive Portal. A built-in captive portal is described below. With multiple overlay tunnel services such as GRE and L2TP in addition to VLAN features, OpenWiFi is also easily deployed with any number of Captive Portal appliance solutions in either in-band or out-of-band style deployments.
Creating a local captive portal involves associating the "captive" service with an interface. In the example below, "captive" is enabled on a downstream role interface. Any associated SSID on LAN side of this Access Point will be subject to configuration of the local captive portal. This would also apply to LAN interfaces if also associated with "captive".
Local captive portal will redirect to a default landing page and display the name as configured in "gateway-name". Per associated user bandwidth and usage quota limits and total association limits may all be defined.
TIP OpenWiFi 2.0
When an external access controller, such as a captive portal appliance or a Universal Access Method (UAM) redirector is required to handle subscriber login, OpenWiFi optionally supports builds that include use of CoovaChili. This would be found in build profile chilli-redirect.yml.
To configure a CoovaChilli service, OpenWiFi supports the "third-party" schema definition.
Through the use of third-party, many configurations are possible, for external captive portal, third-party will process a services lookup of "chilli-redirect" applied to an interface.
Within "third-party" will be the necessary CoovaChilli configuration parameters.
Associate to an interface:
In the above example, captive portal redirection occurs via a NAT interface on LAN side or "downstream" role.
When a direct to WAN presentation, or bridge mode operation is desired, associate the service to the "upstream" interface.
Associate to an interface: