Integrating your Exinda Appliance with a 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 DNSDomain Name Server traffic for the unauthenticated users is not blocked.

Since the Exinda Appliance matches traffic to the filters in the policies (and virtual circuits) from the top of the Optimizer policy tree, you need to ensure that the most specific filters appear first in the tree. 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.

If you have a single authenticated users group, you can create separate virtual circuits for the authenticated and unauthenticated users. Multiple policies can then be added to the authenticated user virtual circuitlogical definitions that partition a a physical network circuit and used to determine what traffic passes through it and how much to manage these users.

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.

Using virtual circuits to filter for authenticated traffic

However, 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 explicitly filters in favour of 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.

Using the policies themselves to filter for authenticated traffic

Related Topics

• Configure Network User Groups
• Creating a Virtual Circuit for Authenticated Users
• Creating a Virtual Circuit for Unauthenticated Users
• Creating policies to filter for Authenticated Users with no Virtual Circuit available
• Creating policies that redirect traffic
• Creating policies that block unwanted unauthenticated traffic