Step 4: Create the Captive Portal Page
This brings us to the Portal page contents. The Portal page is displayed when a client first attempts to connect through the Portal. Access to the Internet is blocked until the user brings up a web browser and clicks the Submit button on the webpage that will appear. Clicking the Submit button indicates that they have read and understood the contents of the page. The user is then allowed access to the Internet via the Portal, still restricted by any firewall rules that may be in place until either the idle or hard timeout is reached.
The Portal page contents are customisable and you can upload any valid HTML from a file as long as it contains the following form HTML
<form method="post" action="">
<input name="accept" type="submit" value="I Agree">
</form>
Note that while the example above shows the value of the submit button to be “I Agree”, it can be anything you like. Typically the Portal page would contain information regarding any restrictions in place and an Acceptable Use Policy (AUP).
You might notice that there is no way of uploading content files such as images to m0n0wall for the Portal page. As discussed in the previous article, m0n0wall is designed to run completely from RAM so images, Flash objects, etc. would quickly start eating into available memory. You can, however, host content files elsewhere, such as a webserver on the LAN interface or on the Internet and reference them in your uploaded Portal Page contents HTML. These can be added using HTML syntax like:
<img src="http://portal.dave-cook.org.uk/images/CommunityCafe.gif">
This on its own isn’t enough, however, since m0n0wall will block access to the webserver until the Submit button on the Portal page has been clicked! This would also be the case if you had whole websites that you would want Portal clients to be able to access before they were granted free access to the Internet. This could be an FAQ about the Portal service itself, or the websites of sponsors and advertisers.
Fortunately, the Allowed IP Addresses feature allows you to unblock access to specific IP addresses that clients can freely access without being required to pass through the Portal page. This functions in two ways.
- To IP addresses – allowing access to remote websites and such
- From IP addresses – which could be used to allow known clients with statically configured IP access to the Internet
Updated 2 October 2004
Figure 6 shows that I have allowed access to my webserver on the LAN for the Portal page images and to two other Internet websites that I am promoting on the Portal page. Configuring access to websites with IP addresses, rather than their DNS name, can cause problems if the sites move IP addresses frequently or like www.tomshardware.com, have multiple IP addresses which would all have to be configured separately.
The final entry is in the opposite direction, allowing my wireless access point to addresses beyond the Captive Portal. This is so that I can use its web adminstration from the LAN network, without this reponses to my connection attempts from the LAN network would be blocked by the Captive Portal.
Figure 6: Captive Portal – Allowed IP Addresses
(click on the image for a larger view)
Access to known clients can also be granted by MAC address using the Pass-through MAC page. This is a better method than static IP addresses, as it allows the client to still pick up their IP configuration by DHCP.
As an example, my finished Portal page is shown in Figure 7. It is not going to win any prizes for website design, but all the basic elements are there. The Acceptable Use Policy (AUP) was created by amending the AUP in place at www.piertopier.net. If you want to use it as a starting point it downloadable here as a text file, and the page HTML here.
No comments:
Post a Comment