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 completeing 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. 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
The User Authentication tab has settings to control how users are authenticated and settings related to session management.
User Authentication can be set to None, Local Directory, RADIUS, or Active Directory. When users are logging into the portal page, authentication will done using the selected method. None is useful if when only presenting a EULA/message and not requiring a username/password on login.
Session Settings control several aspects of authentication. Idle Timeout is the time that passes before an idle client is automatically logged out. If set to 10 then clients that send absolutely zero traffic for ten minutes will be automatically logged out. A setting of zero is disables Idle Timeout. Timeout is the time that passes before a client is automatically logged out. If set to 60 the client will have to re-login every 60 minutes. This setting can be set to a minimum of 5 minutes. Logout Button Popup enables a popup on login. If enabled clients will see a pop-up with a logout button that can be used to explicitly log out. Some browsers and pop-up blockers will block this by default. Allow Concurrent Logins controls whether two machines can use the same login credentials. If enabled, two machines can both login with the same username/password at the same time.
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 with the Active Directory Login Script?
It is not suggested to use two simultaneous but different ways to indentify user traffic. Both Captive Portal and the ADLS can be used to map IP to usernames, but using both at the same time can lead to confusing results. 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.
