Captive Portals

The captive portal view presents the scaffolds that configure the behavior of the rXg forced browser redirect mechanism.

The initial forced browser redirect is configured via the splash portals scaffold. Once a device has acquired an IP address via DHCP or via static assignment, the rXg enforces policy based on the group membership. In a typical scenario, most devices will initially be members of an IP group that spans the entire subnet from which the IP address of the device is assigned. To enable the forced browser redirect, the IP group must be configured with a policy that is associated with a splash portal record.

Once redirected to the captive portal specified in the splash portal record, the end-user must present credentials to access the WAN. The supplied credentials determine the new group that the device will be a member of. In a typical scenario, the end-user will supply a username / password pair or a token code that is associated with a account group. If external identification is used, the device will be associated with a RADIUS group or LDAP group.

To complete the captive portal configuration, the new group must be associated with a policy that is linked to a landing portal. In addition, the new group be of a higher priority than the first group. In a typical scenario, the new group is associated with a policy that is linked to several other enforcement mechanisms (e.g., bandwidth queues, multiple uplink controls, web experience manipulation, etc.).

Splash Portals

Splash portals define the pre-authentication settings that are used when forced browser redirect is in effect.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The portal field determines the local captive portal that will be used for pre-authentication. The default RG Nets portal is always available as a choice from this list. Additional choices for the portal field are determined by the custom portals scaffold on the portals view of the system module.

Setting the remote checkbox specifying a remote URL enables forced browser redirect to a captive portal web application that is stored on a remote host. Using a remote host for the pre-authentication pages is not recommended for typical deployment scenarios due to increased latency and complexity. In most clustering and multi-unit central management scenarios, a customized local pre-authentication portal contains hyperlinks to a centrally served portal for unified end-user credential management.

The following substitutions are available for the remote URL :

%url% - the original URL (desired URL) that the end-user surfed to
%rxg% - the name of the rXg that executed the redirection
%ip% - the IP address of the end-user
%mac% - the MAC address of the end-user
%wan_ip% - the WAN NAT IP address of the end-user
%wan_mac% - the MAC address of the interface for the Uplink the user is assigned to
%wan_mac_last6% - The last 6 characters of the WAN MAC, excluding colons
%hostname% - the DHCP client hostname of the end-user
%group% - the name of the group that the end-user was a member of during redirection
%policy% - the name of policy that the end-user experienced during redirection
%landing_portal% - the name of the splash portal that the end-user was presented
%portal_controller% - the name of the custom portal controller that the end-user was presented
%logged_in% - true or false depending on whether or not the end-user is logged in
%random_number% - a random eight digit integer
%error% - an error string
%notice% - a notice string
%exception% - an exception string
%action% the custom portal action that the end-user was redirected to
%redirect_action% - the custom portal action/view that the end-user was redirected to after processing the request
%vlan% - client VLAN tag, if any
%ap_mac% - MAC address of the AP to which the client is currently connected

An example of a remote URL that utilizes substitution is:http://central.srvr/port_app/?orig_url=%url%&subcriber_ip=%ip%

The whitelist field enables the operator to choose one or more wan targets that list IP addresses and/or DNS entries of websites that are to be exempt from the forced browser redirection policy configured by this splash portal record. There are many common uses for the whitelist. When credit card payment gateways are used, the payment gateway servers may need to be whitelisted in order for payments to be processed. If pay-per-click advertising is placed on the pre-authentication portal, the advertising destinations must be in the whitelist to enable proper click through and tracking. Cluster configurations require the cluster controller to be in the whitelist to enable unified user management. In addition, many operators use the whitelist to enable unfettered access to a handful of websites of their choosing.

The configuration options in the automatic login section defines how the rXg captive portal behaves when a account with automatic login enabled joins the network and does not have an existing session. Enabling background mode and/or the portal mode allows accounts with automatic login enabled to connect without having to enter credentials at the captive portal.

If background mode is set to MAC , then the rXg will continually poll the ARP table and/or DHCP leases (as defined by the MAC to IP mapping setting in the device options). The rXg will then automatically create sessions for accounts with automatic login enabled, thus obviating the need for the account to login via the captive portal. If a login session is created by the rXg via the background mode then the end-user will never experience forced browser redirection. Enabling background mode is sufficient for handling most cases of automatic login. However, if the rXg becomes heavily loaded, then the polling nature of background mode automatic login may result in some end-users browsers experiencing forced browser redirect. Thus automatic login is also implemented in the captive portal and enabled via the portal mode option. Disabling the background mode may be necessary to operate in extremely high load environments. Disabling background mode may also be necessary when deploying the rXg in conjunction with certain wireless infrastructures that spoof MAC addresses.

If portal mode is set to anything other than disabled , then the rXg will attempt to create a session and/or login to the portal for accounts with automatic login enabled when a device with a matching MAC address hits the portal. The MAC (create session only) option creates a login session for the account but does not log the account into portal. Thus the end-user web browser is denied access to the profile information stored in the account. This option is most appropriate for high transient environments such as hotspots, hotzones, hotels, conference centers, etc. The MAC (create session, login to portal) creates a login session for the account and also logs them into the portal. This option is most appropriate for fixed wireless broadband environments where the end-user population is mostly static. The MAC AND cookie option is similar to the MAC (create session, login to portal) in that a session is created for the account and the web browser is granted access to the portal. However, in addition to checking for the MAC address, the browser is checked to make sure that a cookie matching one stored by the rXg during previous portal activity is present. This is the most secure method of enabling automatic login but it requires that the end-user bring up the same web browser that they used the last time they interacted with the rXg captive portal. The MAC OR cookie option is similar to MAC AND cookie , except the user's MAC address can have changed as long as there is still a matching cookie in the user's browser. This is useful for situations where a user switches between a wired and wireless connection, thereby changing MAC address. The MAC mode checks only the MAC address. The cookie mode checks only the browser cookie.

The WISPr settings are arbitrary strings that pass meta-data to WISPr client software. Consult the documentation that is provided by wireless service aggregrators for the proper settings for these fields.

The TOS checkbox enables a terms of service requirement for the pre-authentication captive portal.

The policy field relates this record to a set of groups through a policy record.

The shared credential groups field determines which shared credential logins are to be accepted by this portal.

The usage plans field determines which usage plans are to be displayed and accepted by this portal.

Landing Portals

Landing portals define the post-authentication settings that are used when forced browser redirect is in effect.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The portal field determines the local captive portal that will be used for post-authentication. The default RG Nets portal is always available as a choice from this list. Additional choices for the portal field are determined by the custom portals scaffold on the portals view of the system module.

Setting the remote checkbox and specifying a remote URL enables post-login browser redirect to a captive portal web application that is stored on a remote host.

The following substitutions are available for the remote URL :

%url% - the original URL (desired URL) that the end-user surfed to
%rxg% - the name of the rXg that executed the redirection
%ip% - the IP address of the end-user
%mac% - the MAC address of the end-user
%wan_ip% - the WAN NAT IP address of the end-user
%wan_mac% - the MAC address of the interface for the Uplink the user is assigned to
%wan_mac_last6% - The last 6 characters of the WAN MAC, excluding colons
%hostname% - the DHCP client hostname of the end-user
%group% - the name of the group that the end-user was a member of during redirection
%policy% - the name of policy that the end-user experienced during redirection
%landing_portal% - the name of the splash portal that the end-user was presented
%portal_controller% - the name of the custom portal controller that the end-user was presented
%logged_in% - true or false depending on whether or not the end-user is logged in
%random_number% - a random eight digit integer
%error% - an error string
%notice% - a notice string
%exception% - an exception string
%action% the custom portal action that the end-user was redirected to
%redirect_action% - the custom portal action/view that the end-user was redirected to after processing the request
%vlan% - client VLAN tag, if any
%ap_mac% - MAC address of the AP to which the client is currently connected

An example of a remote URL that utilizes substitution is:http://central.srvr/port_app/?logged_in=%logged_in%&subcriber_ip=%ip%

The blacklist field enables the operator to choose one or more wan targets that list IP addresses and/or DNS entries of websites that are always to be redirected to the captive portal web application selected in this landing portal record. In a clustering scenario, it may be useful to redirect certain web accessible cluster resources back to the post authentication portal for load balancing. In an advertising scenario, it may be useful to redirect access for particular websites to the local captive portal web application so that focused local content is delivered over generic content.

The session restrictions settings control the length of the end-user session as well as the automatic logout mechanism. The settings here may be overridden by various other configuration settings of the rXg. For example, if external RADIUS authentication is being utilized, the RADIUS Class attribute may be consulted to configure the session length. Another example is if the account has automatic login enabled. In that case, the portal will not be displayed again until the user no longer has any usage minutes.

Set the amount of time that an end-user is allowed to be logged on before they need to login again using the restriction field. If unlimited login time is desired, check the unrestricted box.

Check the no idle timeout box to disable the automatic logout upon idle feature of the captive portal web application. Account usage minutes will continue to be depleted regardless of traffic when the automatic logout feature is disabled. Alternatively, set a idle timeout to enable the automatic logout feature.

The grace time field enables the captive portal web application to allow end-users to be logged in for a short amount of time to complete the selection and purchase of a usage plan.

The redirect URL field enables the operator to redirect the end-user to a configurable URL after successful login. Check the original box to redirect the user to the URL she requested before being redirected by the captive portal. Leave both fields blank to display the post login success page of the landing portal.

The policy field relates this record to a set of groups through a policy record.

The usage plans field determines which usage plans are to be displayed and accepted by this portal.

Portal Mods

Portal Mods allow the operator of the rXg to modify an existing portal, content can be modified by selecting the view and adding HTML content that will replace the view. Images can also be replaced as well. This allows the operator to easily change images and specify the login options for example.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The Custom field allows the operator to select the custom portal the Portal Modification record applies to.

The Splash and Landing fields allow the operator to select which Splash and Landing portals the record will apply to. This allows the operator to use the same portal but have different changes to either the Splash or Landing side of the portal(s).

The Splash field allows the operator to specify the Splash portal(s) the Portal Modification will apply to.

The Landing field allows the operator to specify the Splash portal(s) the Portal Modification will apply to.

The View field selects the view in the portal that will be modified.

The HTML(ERB) field, contains the code that will modify the selected view.

The Image field, is used to upload an image to replace an existing image in the portal, or can be used to upload an image to be used in the HTML(ERB) field.

The Image to Replace field combined with the Image field allows the operator to replace and existing image on the portal with a custom image.

For examples of how to use Portal Mods see the Portal Customization::Portal Modifications section of the manual.

WiFi Profiles

The Name field is arbitrary and can be set to anything.

The SSID field is used to set the SSID that will be contained in the profile that the client device will connect to after downloading the profile.

The Default checkbox, if checked specifies that this WiFi Profile will apply to all landing portals.

The Server Certificate field allows the operator to specify the SSL certificate that will be included with the profile.

The Landing Portals field allows the operator to specify which landing portal(s) will present the WiFi Profile when the client device successfully connects.

WiFi Profiles allow the operator of the rXg to configure the profiles that will be downloaded to the client device when it succesfully connects to the network. The profile contains the information to connect to the network and installs the certifcate on the device.