Tech, Gadgets, Photography, Social Media and Poor Spelling
What is a captive host?
Have you ever connected to a “free wifi” system at a Starbucks or a Airport, you connect to it, then automatically get redirected to a portal where you need to enter a login. Thats a Captive portal, until you enter the correct credentials it holds you captive.
After locking down out office network, I’ve been asked to put one of these systems together. Not as easy as you might think. There are a lot of systems which rely on you using a certain type of Linksys Router and changing the firmware. However I found a great little solution..
Untangle is actually one of those systems where they seem to offer a free, and then several level of paid for services on top. However the Captive portal part is free.
Download and install the core server from here.
Then follow the Wiki page instructions
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.
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.
This section reviews the different settings and configuration options available for Captive Portal.
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 Captureunchecked.
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.
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.
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.
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 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.
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.
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.
Login Event Log
Use the following terms and definitions to understand the Login Event Log:
timestampThe time the event took place.clientThe client IP address.usernameThe client username (if applicable).actionThe action taken for the client.authenticationThe 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 theCapture 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:
timestampThe time the event took place.actionThe action taken for the client.clientThe client IP address.reasonThe reason why the client was blocked.serverThe server the client was attempting to contact.
Once installed, if you’ve ever used one of these systems, its about 10 minutes to setup and get working. and Bingo, your captive..