Integrating Exinda with your Captive Portal

The Exinda appliance can be a part of a captive portal system by using the HTTP Redirect policy to redirect unauthenticated traffic to the login page of your captive portal system.

When users have authenticated with your captive portal, your portal system sends the login user information and the group to which you want the user to belong, to the Exinda appliance through the appliance Active Directory API. You may choose to have a single authenticated user group or you may choose to have several user groups to indicate a level of service, such as Gold, Silver, and Bronze service levels. On the Exinda appliance, you need to create user-group network objects that link with these Active Directory groups, which then identify the traffic as belonging to authenticated users. In the Optimizer policy tree, you need to create policies for the authenticated traffic using the user group network objects and you will also need to create a policy to redirect unauthenticated HTTP traffic to your captive portal and another policy to block other types of unauthenticated traffic. You should note that you should ensure that DNS traffic for the unauthenticated users is not blocked.

	Version Info: The HTTP Redirect policy is available in 7.0.1 and above (in the 7.0 firmware product line) and in 6.4.5 and above (in the 6.4 firmware product line).

Since the Exinda appliance attempts to match the traffic to the filters in the policies (and virtual circuits) in a top-down order in the Optimizer policy tree, you need to set up the series of policies with the most specific filter criteria appearing first in the policy tree, which means that the policies should appear in the following order.

1. Authenticated traffic, to which you may want to apply various policies
2. Remaining (unauthenticated) HTTP traffic, which you will redirect to a login URL using the HTTP Redirect policy
3. Remaining (unauthenticated, non-HTTP) traffic, which you may want to block or throttle.

Note When redirecting traffic to a URL, take care to ensure that traffic to that URL does not fall into the redirect policy as this will cause a redirect loop. This will not be an issue if the captive portal is on your local network such that traffic from the unauthenticated users can get to the captive portal directly without going through the Exinda appliance. If the captive portal is positioned such that the unauthenticated users traffic goes through the Exinda appliance, then add a policy before the redirect policy that will capture the traffic to the captive portal and will allow it through.

If you have a single authenticated users group, you can create separate virtual circuits for the authenticated users and unauthenticated users, then multiple policies can easily be added to the authenticated user virtual circuit to manage the authenticated users traffic. Note that both virtual circuits can be specified as requiring 100% of the available bandwidth with automatic handling of over-subscription. This allows the bandwidth to be shared. However, since unauthenticated traffic requires very little bandwidth, the authenticated users will get almost all of the bandwidth.

Figure - Using virtual circuits to filter for authenticated traffic

Alternatively, if you have multiple groups of authenticated users where you want one group to have preferential treatment over the other groups, you need to create a series of policies within a single virtual circuit, where each policy intended for the authenticated users explicitly filters for the authenticated users. Using virtual circuits to filter authenticated traffic is easier if you have many policies that you want applied to the authenticated traffic. However, since only policies, not virtual circuits, can ensure preferential treatment of the traffic, you need to use policies to filter the authenticated user groups.

Figure - Using the policies themselves to filter for authenticated traffic

To create a network object from an Active Directory user group

See Configure Network User Groups.

To create a virtual circuit for authenticated users

1. Specify the Virtual Circuit Bandwidth to be 100%.
2. Specify Oversubscription handling to be Automatic.
3. Specify the Network Object to be the network object for the Active Directory authenticated users group.

To create a virtual circuit for unauthenticated traffic

1. Specify the Virtual Circuit Bandwidth to be 100%.
2. Specify the Oversubscription handling to be Automatic.
3. Specify all the Filter Options to be ALL, including the Network Object field.

To create a policy that filters for authenticated users (when you are not using a virtual circuit to do the filtering)

1. Specify the Action to Optimize and specify the bandwidth, acceleration, and packet marking settings as desired.
2. For each filter row
   1. Specify the Filter traffic Source to be the network object for the Active Directory authenticated users group
   2. Specify the Filter traffic Direction to be Both
   3. Specify any other Filter options that you want, such as setting a particular application or application group.

To create the policy that redirects the traffic

Figure - Configuring a HTTP Redirect policy

1. Select HTTP Redirect as the policy action.

2. Specify the URL that you would like the unauthenticated user to be redirected to in the Redirect URLfield.
   Traffic matching this policy is forwarded to the specified URL, which causes the specified URL to be presented to the client.

3. Type the Filter Rules.

   The only allowable applications are HTTP, HTTP-ALT, and HTTPS. The recommendation is to add three filter rules, one for each of these applications. Similar to other policy configurations, in conjunction with the application, if needed you can specify VLAN, Host/Direction/Host, or ToS/DSCP.

To create a policy that blocks remaining unauthenticated traffic

1. Select Discard as the policy action.
2. If you want to block all unauthenticated traffic, then do not check the Discard only the first packet of the connection checkbox.
3. And do not set any filter rules.