Introduction
The freedom of wireless networking is now a reality for everybody with a suitably equipped device. At one time too expensive for everything other than corporate use on a business network, Wi-Fi is now mainstream. In many respects, this is due to Intel’s extensive marketing of its Centrino brand, launched in mid-March 2003.
Despite concerns over the relative insecurity of WEP encryption, wireless networks are everywhere. The speed increase and value for money offered by 802.11g has only accelerated the take-up, increasingly by home users attracted by being able to network computers together and share broadband Internet connections.
It is not just home users that now want to share access. Taking lead from the big-boys such as Starbucks, Costa Coffee and McDonalds among others, even the small coffee shop and diner owner wants to provide wireless Internet access as a value-added service to their laptop PC and PDA using customers. The D-Link Airspot and SAGEM F@st range of Hotspot Gateways are two of a number of commercial devices that have been developed specifically for this growing market complete with user control, ticket printers and billing.
However there is another more altruistic group of wireless Internet providers such as NYCwireless (New York City), Socal Free Net (San Diego) in the USA and Airwan (Cardiff) and Pier To Pier (Brighton) in the UK. These community projects are driven by people willing to share spare bandwidth on their Internet connections with the public at large for free.
Here though, free is as in ‘free beer’, rather than free as in ‘freedom’. While members of these groups are more than happy for their spare bandwidth to be used, the last thing they want is for their bandwidth to be abused. The functionality in m0n0wall can assist in giving a degree of control over this.
So what is a Captive Portal?
The m0n0wall [reviewed here] implementation of a Captive Portal was introduced in one of the early betas of m0n0wall v1.1 earlier this year. This was largely the work of Dinesh Nair with assistance from Manuel Kasper and the other m0n0wall developers.
Basically, the Captive Portal is a web page that users/clients are forced to visit before they are granted access to the Internet. This web page can have a number of purposes, but primarily it allows you to:
• Notify users of your Acceptable Use Policy (AUP) which they have to agree to before they are granted access to the Internet.
• Tell users anything else relevant to the access they are being granted, ports and services that are restricted, details of sponsors, who they should buy beer for in thanks 🙂 etc.
Alternatively, the Captive Portal can configured to authenticate users with a UserID and Password against a RADIUS server before they are granted Internet access. RADIUS is a standard protocol for remote user authentication and accounting used in “enterprise” grade networks and by some ISPs.
This has given rise to widespread support for RADIUS by most Unixes and Unix-like operating systems. MS Windows Server also has an implementation called Internet Authentication Services which authenticates against both local accounts and a centralised NT4 Domain or Active Directory.
User Authentication is of more relevance on a private network as a way of controlling access to the Internet. So for this article, I will concentrate on configuring the Captive Portal for unauthenticated access.
Using a Captive Portal to access the Internet
For the purposes of this article, let’s imagine a Community Cafe. In the Cafe, there are a number of open access PCs connected to an Ethernet network. The Cafe also provides a wireless network for customers visiting with laptop PCs and other wireless devices.
I’m using the straightforward scenario of a Cafe, but this could just as easily be someone sharing broadband Internet with their immediate neighbours, or a school or other educational institution.
Figure 1 shows a diagram of my hypothetical Cafe network. The Internet connection is some sort of broadband, cable, xDSL etc. and the Cafe network is physically connected by a router on the WAN interface of a m0n0wall firewall (grey).
Figure 1: Community Cafe Network
(click on the image for a larger view)
The m0n0wall firewall has two further interfaces: the LAN interface that connects PCs used in the administration and day-to-day running of the Cafe (green); and the PORTAL interface that connects to a wired Ethernet LAN (in green) and wireless LAN via an access point (in orange) to provide client devices managed access to the Internet.
In running this network for the Cafe we need to:
- protect PCs used for running the Cafe (connected on the LAN interface) from both the Internet and clients on the PORTAL interface
- protect clients connected on the PORTAL interface from the Internet
- control the Internet ports and services clients connected on the PORTAL interface can use
- ensure that clients using the Internet first agree to an Acceptable Use Policy before granting access
You’ll see that m0n0wall provides all the necessary functionality to meet these requirements.
Connecting the Cafe Admin and Open Access PCs is relatively straightforward. All that’s required is a couple of Ethernet hubs or switches – one is connected to the LAN interface of the m0n0wall firewall for the Cafe Admin PCs, the second to the PORTAL interface for the Cafe Open Access PCs and wireless access point.
Customers of the Cafe could then use one of the fixed Open Access PCs provided which would already be configured for using the Internet. Customers with their own notebooks would have to do some simple configuration so they can use the wireless hotspot:
- Configure the wireless adapter to be a DHCP client (Obtain IP address automatically)
- Select the Captive Portal’s SSID to connect
Both groups of customers would find that initially, general access to the Internet would be blocked. To access the Internet, they would need to launch a web browser. When the browser attempts to connect to its Home Page, it will be redirected to the Portal’s Terms and Conditions or Acceptable Use Policy on the Portal Page. Internet access will be granted by simply clicking on an “I Accept” or similar button on this page until the alloted connection time expires.
Tip: If we were only providing a wireless hot-spot for customers with laptop PCs etc, the wireless access point could be connected directly to the PORTAL interface of the m0n0wall using a CAT5 cross-over cable in place of a hub/switch and two normal CAT5 cables.
Setting it all up
We’ve had a quick look at the structure of a network where the Captive Portal may be useful and how it will allow us to control access to the Internet. Let’s now look at the detail of getting it configured and running.
The basics of m0n0wall were covered in my previous article covering v1.0 of the software. If you are new to m0n0wall, this covers hardware installation and getting m0n0wall up and running. The set up process below assumes you already have a version of m0n0wall v1.1 running on either a standalone PC or one of the embedded PC platforms I discussed in my m0n0wall review.
The steps are:
- Configure the PORTAL network interface
- Configure DHCP to hand out a suitable IP configuration to clients (PCs and other devices)
- Configure the Captive Portal itself, connection time-outs etc.
- Upload the HTML for the portal page
Step 1: Configure the PORTAL network interface
m0n0wall requires a minimum of two physical network interfaces for the LAN and WAN. You could run the captive portal on the LAN interface, however this would allow anonymous users access to any of your PCs/Servers on the LAN as well as your Internet connection unless you connected those users via a VLAN-capable switch.
A more secure method is to put the Captive Portal on a separate interface in the same way as it is good practice to put Internet-facing servers on a separate interface, normally referred to as a DMZ (demilitarised zone). As I pointed out previously, this has the benefit of letting you establish separate firewall rules for the two classes of users.
m0n0wall handles additional network interfaces as Optional interfaces. In my case, I’m using a PC Engines WRAP, so I have a third physical Ethernet interface that I am going to use for the Captive Portal. As you can see in Figure 2, m0n0wall allows you to rename the interface for ease of identification.
Figure 2: Configuring the PORTAL interface
(click on the image for a larger view)
Note that the network address / subnet used isn’t too important as long as it is not the same as your LAN and either:
- a private network that meets RFC 1918 (10/8, 172.16/12, 192.168/16), typically a network between 192.168.1.0/24 and 192.168.254.0/24
or - a subnet of public IP addresses assigned by your ISP and routed to your m0n0wall
I used 192.168.11.0/24 (subnet mask 255.255.255.0) which allows 254 valid IP addresses. Of those I have assigned:
- 192.168.11.1 to the Portal interface of m0n0wall
- 192.168.11.2 to the wireless AP
To provide wireless access, I am going to use a stand-alone access point instead of trying to use m0n0wall’s built-in wireless support. This lets us use any off-the-shelf access point instead of limiting us to the relatively small set of WLAN chipsets supported by m0n0wall (and FreeBSD). It also frees us from having to use a mini-PCI WLAN card with either the Soekris or PCEngines WRAP embedded platforms or having to add a PC Card / CardBus adapter so that we can use a CardBus WLAN card with a desktop.
I used a BuffaloTech WLA-G54C-1 G54 Compact Access Point while writing this article. It’s relatively inexpensive (I paid around $74) and supports both 802.11b and 802.11g standards. For more details, please have a look at Tim Higgins’ review. Since I didn’t have a cross-over cable handy, I simply plugged the Portal interface of the WRAP and the AP into a 10mbps hub.
I won’t be covering the configuration of the AP itself in this article, since that’s adequately covered by your AP’s user manual and there is nothing in particular that needs to be set for use with the m0n0wall Captive Portal.
Step 2: Configure DHCP
The next step is to configure DHCP on the PORTAL interface to allow Captive Portal users to automatically pick up their IP configuration when they connect. Here you need to allocate a range of IP addresses which will be leased. Figure 3 shows that I allocated 192.168.11.101 to 192.168.11.150, effectively restricting the captive portal to 50 concurrent users. You also need to enable the DHCP server on the PORTAL interface using the ‘check-box’ at the top of the screen.
Figure 3: Portal Interface DHCP configuration
(click on the image for a larger view)
As I am not expecting lots of users, I have left the DHCP lease times at their default settings. On a busy Captive Portal with many users you may want to set the lease time similar to the hard timeout.
Step 3: Configure the Captive Portal
Now we need to configure the Captive Portal itself. Figure 4 shows there are three tabs for this: Captive Portal; Pass-though MAC; and Allowed IP Addresses.
The first thing to do is choose the interface to run the Captive Portal on. You can see I’ve chosen the optional interface, PORTAL, that I previously configured. Next are the timeouts – idle and hard – that disconnect a client from the portal. The timeouts are just a tidying-up process, since in our no-authentication setup, clients are able to immediately reconnect to gain access to the Internet. The idle timeout disconnects a client after the defined period of network inactivity and the hard timeout forces client disconnection after the programmed period from the start of the current connection.
Figure 4: Captive Portal Configuration
(click on the image for a larger view)
The Logout popup window checkbox controls whether a popup window with a logout button comes up when clients are first allowed through the portal. It allows clients to manually disconnect themselves before the timeouts occur.
Figure 5: Captive Portal Logout Popup
The RADIUS server and Authentication error page areas are used to configure the Portal to authenticate users with a username and password before they are granted access. These aren’t relevant for enabling open access, so I won’t cover them here.
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.
Figure 7: Finished Portal Page
(click on the image for a larger view)
Captive Portal Management
Once the Captive Portal is set up, there is little to do in the way of ongoing management. You can keep an eye on how many clients and who have connected via the Status -> Captive Portal page. You can also forcibly disconnect clients, though there is no way of permanently barring them from the Portal.
Figure 8: Captive Portal Status
(click on the image for a larger view)
If you really had a problem client, you could attempt to stop them from using the Portal by statically allocating an IP address to their MAC address and then blocking this IP address with a firewall rule. Not elegant, but it could work with someone with little technical knowledge. However, this is easily circumvented by somebody either manually configuring a valid static IP in the same range and connecting with that, or ‘spooifng’ the MAC address of their wireless interface so they appeared to the portal to be another client, something relatively simple to do under MS Windows 2000 and XP.
Security
Something you have to pay attention to when allowing unknown clients access to your networks and Internet connection is security. m0n0wall is relatively secure by default, however there are a few things to consider:
- Don’t allow the portal subnet access to ANY in a firewall rule
Using ANY will grant access to all networks connected to the firewall, including the network on your LAN interface and any other optional interfaces. - Block direct access to your PORTAL interface IP address and your WAN interface IP address from your portal network
This will prevent Portal clients from being able to access the m0n0wall administration GUI. - Block access to SMTP (port 25) from the Portal network
Since most people have access to web mail, this will prevent users from intentionally (Spammers) or unintentionally (those inadvertently infected with Viruses, Trojans and Worms) sending out bulk email from your Internet connection. - Limit the bandwidth available to your portal network with Traffic Shaping
If you are using your Internet connection for other purposes than the Captive Portal – providing Internet access to your LAN for example – limit the bandwidth available to your Portal network with m0n0wall’s Traffic Shaping features. This will prevent clients on the portal network from using all available bandwidth.
Figure 9 shows the firewall rules I placed on the PORTAL interface that adequately protect my network while still allowing fairly free access to the Internet for the portal clients. The first three rules block all NetBIOS traffic – an essential practice on all Internet-facing connections. These are followed by a rule blocking all outbound SMTP (Port 25) connections.
Figure 9: m0n0wall Firewall Rules on the PORTAL interface
(click on the image for a larger view)
The fifth rule down blocks HTTP connections to the PORTAL interface itself (m0n0wall will allow Web Admin on all interfaces if firewall rules allow). This is followed by a similar rule that blocks HTTP connections to the small subnet between the WAN interface of the firewall and the inside interface of my DSL router, again stopping Web Admin access on both the m0n0wall and my DSL router.
Second to last is a rule that allows access to my LAN, but only for HTTP to a server (HOMER) that hosts the images for the portal page. The last rule allows any connection (if not previously blocked) to anywhere other than the LAN network.
Dana Spiegel, director of the community-based organization NYCwireless, has stated: “NYCwireless has a totally unrestricted network where we’ve never seen a spammer send out millions of spam messages”.
One approach suggested is to severely limit the bandwidth available for SMTP mail to discourage anyone from sending bulk email. In the end, it is the decision of whoever provides the Portal / HotSpot and what they are comfortable with.
Conclusion
I have shown how m0n0wall v1.1 can be used to allow free, but controlled, access to the Internet. Like m0n0wall in general, the implementation is relatively simple but very flexible, as one user pointed out when I was researching this article:
“What I like is that you can build a wireless DMZ using completely different types of APs (wireless access points) and it doesn’t make a difference because the m0n0wall is doing all of the authentication and firewalling. So really those APs become nothing more then dumb bridges.”
In the true spirit of a Open Source project, the m0n0wall Captive Portal doesn’t provide any functionality for metering and billing the Captive Portal clients. If you want these features, you’ll have to look to commercial products.
The main potential difficulty of providing ‘open access’ is the inability to permanently prevent a persistent abuser connecting to the Captive Portal. This is not a limitation particular to the m0n0wall implementation, just of the anonymous way you are allowing clients to connect and the relative ease of pretending to be somebody different with a simple change of MAC address.
The most common abuse is going to be the persistent ‘bandwidth hogger’. This should be relatively easy to control with a combination of sensible firewall rules, blocking bandwidth-intensive services such as peer-to-peer networks, and controlling the amount of bandwidth in use with m0n0wall’s Traffic Shaping feature. So I’ll show you how to use m0n0wall’s very powerful Traffic Shaping capability in my next article.