Personal tools
Captive Portal
From UntangleWiki
 Captive Portal
|
|
Contents |
About Captive Portal
Captive Portal allows administrators to require network users to complete a defined process, such as logging in or accepting a network usage policy, before accessing the internet. Captive Portal can authenticate users against the Local Directory inside Untangle, RADIUS or Active Directory if Directory Connector is installed. Directory Connector authenticated users can be given special policies using Policy Manager and will be given special per-user reports in Reports.
Getting Started
After installing Captive Portal completing the following steps will work for typical installations.
- Define what users/machines will be "captured" and required to complete the portal process before accessing the internet. For example, enabling the first example rule in the Capture Rules table in the Captive Hosts tab will force all machines on the internal interface.
- Set any "special" IPs that unauthenticated machines will need to access. These can be set in Passed Hosts by adding them to the Pass Listed Server Addresses. Typically this will be the DNS server and the DHCP server if it is on the other side of Untangle. If Untangle is handling these resources this is not necessary.
- Set any "special" machines that always need access to the internet. These can be set in Passed Hosts by adding them to the Pass Listed Client Addresses.
- Customize the Portal Page by editing settings on the "Captive Page" tab. If "Basic Login" is chosen, set the appropriate authentication method for users on the "User Authentication" tab.
- Turn on Captive Portal by pressing the On button on the faceplate.
After enabling, "captured" machines will be forced to "authenticate" on the portal page before accessing the internet. Unauthenticated machines will have all web traffic redirected to the portal page until they have successfully authenticated.
Settings
This section reviews the different settings and configuration options available for Captive Portal.
Captive Hosts
The Captive Hosts tab configures which machines and what traffic will be "captured" by the Captive Portal. This can be done by configuring a set of Capture Rules. Capture Rules describe what traffic is to be captured by Client Interface, Client IP, Server IP, Times of Day, Days of Week, and combinations thereof. The example below shows a rule that captures all clients behind the Internal interface.
All enabled rules are evaluated in order to determine whether or not traffic is captured. Once any rule matches the given traffic no further rules are evaluated. An enabled rule that has Capture unchecked means that traffic will not be captured and no further rules are evaluated. This is useful for special cases where traffic is not to be captured. For example if all Internal machines are to be captured the above example rule can be added. However, if all machines should be given unauthenticated access between midnight and 1AM to grab updates and new anti-virus signatures then a rule can be added at the top with Client Interface set to Internal and Time of Day set to 00:00-01:00 and Capture unchecked.
Capture Bypassed Traffic
The Capture Bypassed Traffic setting determines whether or not bypassed traffic (according to Bypass Rules) are captured. This includes Ping traffic and other bypassed traffic like DHCP. If enabled, even bypassed traffic like Ping, DHCP, and any other bypassed traffic will not pass until a machine is authenticated. If disabled, bypassed traffic will pass even when the machine is unauthenticated. This will need to be disabled if DHCP must pass through Untangle for machines to get addresses. This should be disabled if machines should be able to pass no traffic at all before authenticating.
Passed Hosts
The passed hosts tab is useful for describing machines that should not be captured.
Similar to the Client IP Pass List in Web Filter, machines added to the Pass Listed Client Addresses will have access to the internet without having to authenticate. This is useful for servers that are on a captive network but should not be captive.
Traffic to certain destinations can also be exempt from capture by adding them to the Pass Listed Server Addresses list. Typically this will be the DNS server and the DHCP server if it is on the other side of Untangle. If Untangle is handling these resources this is not necessary. It is also useful for any resources that should be available to all machines despite being unauthenticated such as update servers or servers that are required for the authentication process.
Captive Page
This tab controls the functionality on the portal page displayed to unauthenticated captive users.
Captive Portal Page allows the selection of three different captive pages.
Basic Message is a page used when users should see/accept a message before being allowed to the internet. It has several tunable properties such as Page Title, Welcome Text, Message Text and Lower Text. Additionally if Agree Checkbox is enabled users must check an "accept" checkbox (labeled with Agree Text) before continuing.
Note: All boxes accept HTML code, but invalid HTML will prevent the page from properly rendering.
Below is an example of a Basic Message page a user might see if there is no agree checkbox.
Basic Login is a basic page that requires users to login. Similar to Basic Message it has several properties that can be configured. Once a user hits the login/continue button the user will be authenticated using the Authentication method select on the User Authentication tab.
Note: All boxes accept HTML code, but invalid HTML will prevent the page from properly rendering.
Below is an example of a Basic Login page.
Custom is a setting that allows the uploading of a fully custom Captive Page. This is for experienced web developers that are comfortable with developing and PHP and javascript - Untangle's support department can not help with custom development of custom Captive Pages.
If Custom is selected it is advised to turn off automatic upgrades. Newer versions of Untangle may be incompatible with any custom captive page so the upgrade must be handled by hand. An example Custom Page implementation can be downloaded here.
The View Page Button can be used to view what the configured captive page looks like. This button only works when Captive Portal in on.
Session Redirect
Session Redirect defines how users will be redirected to the captive page.
Redirect URL defines the location that users will be sent after successful authentication. The proper format requires you to enter the http:// for a complete web address otherwise it will not work properly. If Redirect URL is blank they will be sent to the original destination.
Redirect HTTP traffic to HTTPS captive page controls whether users will receive an HTTP or HTTPS login page. HTTPS is more secure as login credentials will be communicated over an encrypted channel, but users will receive a warning without a valid certificate signed by a certificate authority.
Redirect HTTPS traffic to HTTPS captive page controls whether or not unauthenticated users will have their HTTPS traffic redirected to the HTTPS login page. If enabled all HTTPS traffic goes to the captive page. If disabled, HTTPS traffic will be blocked.
User Authentication
User Authentication
This section controls how users will be authenticated if a login page is used as the Captive Page.
None is used in the case where no login is required.
Local Directory can be used if Captive Portal should use the local list of users and passwords in the local directory to authenticate users.
RADIUS can be used if users should be authenticated against a RADIUS server. This option requires Directory Connector to be installed and enabled and configured.
Active Directory can be used if user should be authenticated against an Active Directory server. This option requires Directory Connector to be installed and enabled and configured.
Session Settings
Idle Timeout controls the amount of time a machine/computer can be completely idle before it is automatically logged out. Note: while a machine may be "idle" or "not in use" it is still active on the network level. In this case Idle means zero network activity. This usually happens when a machine is turned off or unplugged from the network.
Timeout controls the amount of time a machine before a machine/computer will be logged out. After this the user must log in again.
Allow Concurrent Logins controls if multiple machines/computers can use the same login credentials simultaneously. For example, if enabled two users can both use the same username and password to login.
Event Log
Captive Portal provides two event logs: Login Event Log and Block Event Log.
Login Event Log
Use the following terms and definitions to understand the Login Event Log:
timestamp The time the event took place. client The client IP address. username The client username (if applicable). action The action taken for the client. authentication The authentication type used.
Block Event Log
The Block Event Log shows all traffic that is being blocked because the source machine has not been authenticated. This is useful for finding out what traffic is being blocked and if there is any that should not be blocked. Often idle machines without logged in users can be active on the network making this log quite large. If there is activity that shouldn't be blocked under any circumstances this can be fixed by modifying the Capture Rules the client and server pass lists or creating bypass rules if Capture Bypass Traffic is unchecked.
Use the following terms and definitions to understand the Block Event Log:
timestamp The time the event took place. action The action taken for the client. client The client IP address. reason The reason why the client was blocked. server The server the client was attempting to contact.
Related Topics
Captive Portal FAQs
Can I use Captive Portal and the Active Directory Login Script?
Yes, provided you make sure to keep them separate - users should not be logging in with Captive Portal authentication set to Active Directory and be running the ADLS. If they are both used, Untangle uses the most recent information to determine the correct username. This can very confusing as the ADLS updates on login and every few minutes and the Captive Portal users will also login after every timeout sometimes with a different username.
Users behind the Captive Portal can't get to the internet and are not seeing the login page. Why?
If clients are using a DNS server outside untangle, you should add this to the passed server list. In order for clients to see the login page, their homepage must successfully resolve and when they try to connect they will see the login page instead of the requested site. If Untangle is providing DNS this is not required.
How can I allow users to log themselves out of Captive Portal?
If you need users to be able to log themselves out, they can put <untangle's_IP>/users/logout to make this happen.
