it-wireless

Thursday, July 07, 2005

Getting the ZoneCD configured

This is a guide to getting the ZoneCD configured. During the boot a series of dialog boxes will be presented to gather the required information needed to get the ZoneCD running. You only need to do this one time. After you complete the configuration it will be saved to floppy for the next boot.

Bash dialogs

Tab will change the selected option, field, or button.
Space Bar is used to make a selection from a group of choices
Enter is used to accept the selection and move to the next screen.
This guide is broken down into sections. The relevancy of each section depends on your selections during the boot. E.g., if you select Closed mode during configuration, the Open mode section will not be very helpful.

ZoneCD version 0.6-0 is displayed. Your display may vary.

The Boot
Open Mode
Closed Mode
Static IP Config
Finishing the Boot


The Boot

OK, here we go. This is the boot splash you will see when the CD starts to boot.




During the boot you will see a bunch of messages going by on the screen. If you see a lot or error messages that look like ":I/O error, dev f0:f1 (cloop), sector ..." you probably had a bad download. Sometimes a file will sustain damage during the download. If you see messages like this, you should delete the iso from your computer and get it again.

Otherwise, if you see none of these messages, just be patient and let the CD continue to boot...



If you are using a USB thumb drive to save your configuration then you may see this screen if the drive is not properly formatted or there is an error in the partition table on the disk. Select to have the zonecd automatically partition and format the drive. NOTE: You will lose all existing data on the drive.
This is a sample of normal output from the programs used to format the USB drive.

This is the Preamble to the GNU General Public License. This will only appear when an unconfigured system is booting. Say yes to continue with the configuration.




If you see this message, then you have not put the floppy or USB thumb drive in. Stick the floppy in the drive or plug your USB drive in, and hit "Enter" to continue. The ZoneCD will not boot without configuration media.




This screen shows up every boot. It gives you an opportunity to change your configuration. A bit of advise, pop the floppy out if you want to reconfigure. I always miss it and need to reboot. This dialog will only wait 5 seconds for you to respond. If you select nothing here on the first boot, the ZoneCD will boot in Closed mode with dhcp for your network configuration.




Select the mode you want your ZoneCD to run in. Closed mode requires that you have already created a login in Zone Control. NOTE: Master logins (email addresses) can not be used to boot the ZoneCD.




Select how you want the ZoneCD to run. This has nothing to do with WiFi, NoCat, or anything else. This is an option for the Operating System. Non - Linux geeks will probably be the most comfortable with GUI (Graphical User Interface).

GUI will give you a basic desktop with a web browser. LessX only starts the X server and a single rxvt session, no window manager. This is done because the ZoneCD boots to runlevel 5, without the rxvt session, you get a broken shell(no job control). NoX should be used on headless systems.


Select the way you want to configure the network for the wired side of the ZoneCD box (the wireless side is hard coded 10.10.10.1)



Open Mode

Enter a URL to redirect your users to after they click the button on the splash page. If you do not want your users to be redirected then select "No Redirect" to have them go to their normal homepage after the splash.




In Open mode you need to tell the ZoneCD to enable or disable the content filter.




Once you finish the Open mode configuration, a screen will display the configuration. Just hit Enter.



Closed Mode

Closed mode requires that you have already created a login in Zone Control. This is required to download your configuration and to send/receive updates from the Control server. Enter the login you created for this zone.

NOTE: Master logins (email addresses) can not be used to boot the ZoneCD.




Enter your password. This is a special dialog that will not display what is typed. This will keep the password from being seen.




OOPS! This dialog could be bad. If you don't get a successful authentication the second, or third time (if you have really fat fingers), then there is no Internet access available. Auto configuration probably failed to obtain an IP address for the wired network connection (eth0), or DNS is failing. But before you panic, switch the network cables and reboot. If this continues, hit the forum.




Once you finish the Closed mode configuration, a screen will display the configuration. Just hit Enter.



Static IP Config

Enter an IP address to use for the wired side network connection (AKA eth0).




Enter the subnet mask to use. Unless you have some special network setup, 255.255.255.0 is safe to use.




Enter the IP address of the gateway. In the example, this is the IP address of a router. This is the suggested setup. The ZoneCD box should be connected to a router, not directly to the Internet.




Enter the IP address of the primary nameserver In the example, this is the IP address of a router. You can also use the IP of your ISP's nameserver.




Enter the IP address of the secondary nameserver. This is optional, if you don't have a secondary nameserver, just leave it blank and hit Enter.



Finishing the Boot
Since the zonecd does not install to your hard drive the files system is mounted on a RAM disk. This requires additional RAM (minimum 128MB )to keep the zonecd running smoothly. You can use the next few dialogs to automatically reboot the zonecd to help keep memory resources optimized.
The ZoneCD uses UTC, aka GMT, to synchronize it's activities with the Control Server. To reboot the zonecd at the correct local time to must select your geographic location.
Select your city, or time zone.
Select the time you want the reboot.

After you complete the dialogs, you will see several messages that update you during the configuration and initialization of your setup.




LessX (shown) only starts the X server and a single rxvt session, no window manager. This is done because the ZoneCD boots to runlevel 5, without the rxvt session (NoX) you get a broken shell(no job control).



GUI will start a desktop session that gives you access to a web browser and a few other goodies.
Your Done! HAVE FUN!!
Everything that needs to be running is configured and ready to go... You don't need to do anything. All that's left is setting up your AP. If you haven't already reviewed the setup guide, you can check it out here...

Setting Up the ZoneCD

The LiveCD is built on Debian Linux. It is helpful, but not a requirement, to have basic knowledge of Linux in order to understand this 'how to'.

You will need the following

High-speed Internet connection
A router for network connection to the Internet (not wireless)
Any WiFi compliant wireless router or access point
A few Ethernet cables
Computer with:
An Intel-compatible CPU
Minimum 128 MB RAM.
Bootable CD-ROM drive.
Floppy Drive
2 Network Interface Cards (NIC's)
Login for Zone Control
I have made the setup of the physical gateway unit as simple as humanly possible. The network configuration of the gateway is something that you should be aware of during your hotspot network and gateway setup.

This is one way to setup the network. There are other ways of doing this as well... This is a very simple guide to help those of you without a lot of experience in networking or WiFi

Network Interface Cards
The gateway(ZoneCD) machine needs to have two NIC's or Ethernet cards. You can imagine the "Internet" flowing through one to the other. For clarity we will label the cards Eth0 and Eth1. Eth0 is the network card that connects to the Internet via your router. Eth1 is the network card that connects to your access point(AP) or wireless router.

During boot time the ZoneCD makes a DHCP client request on both cards, this is part of the Knoppix and Morphix boot config. Eth0 can get an IP address assigned via DHCP from your Internet router or it can be configured during boot to get assigned a static ip. Eth1 will not get an IP via DHCP, it will be assigned a static IP address of 10.10.10.1 later during the boot (10.10.10.1 is the IP address of the network gateway for your wireless clients).

DHCP Server
The ZoneCD runs it's own DHCP server. This is very important in the setup of your wireless network. The AP or wireless router must have the DHCP server shutdown! The AP or wireless router must have the DHCP server shutdown! The DHCP server on the ZoneCD will allow up to 100 clients to connect in the range of 10.10.10.100 to 10.10.10.200. You may use 10.10.10.2 to 10.10.10.99 for any hardware on the wireless network segment... namely the AP. Assign the LAN of the AP a static IP in this range. A good example would be to assign the AP's LAN a static IP of 10.10.10.2. Please visit the forum or check other documentation for configuration of additional "un-authenticated" hardware.

Network Connections
Connect the ZoneCD machine(Eth1) to the AP or wireless router using an Ethernet cable. Connect the cable to the AP's LAN port not the WAN port . If you are using a wireless router, pick a LAN port (usually four LAN ports grouped together and a single WAN port) and plug it in. Do not use the WAN port.

Connect the gateway machine(Eth0) to your router that maintains your Internet connection. This router should be running a DHCP server. If not, the ZoneCD must be assigned a static IP address during boot.



Boot-it-up
With the physical network all hooked up, it is now time to bootup and let the ZoneCD do it's thing. During the bootup you will see a lot of Knoppix/Morphix stuff going-on, you really don't need to be concerned with most of what you will see... just let the CD continue to boot. About half way through the boot, you will be asked a few questions and you'll be done! See How to Configure the ZoneCD for help during the boot of the ZoneCD.

Wednesday, July 06, 2005

Using m0n0wall to create a Wireless Captive Portal

How To: Using m0n0wall to create a Wireless Captive Portal

By David Cook – September 29, 2004
Updated 2 October 2004

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.

Tip: A managed switch supporting 802.1Q VLANs could be used in place of two unmanaged hubs/switches and separate LAN and PORTAL interfaces. m0n0wall would then only need two physical network interfaces, one for the WAN and another for both the 802.1Q LAN and PORTAL virtual interfaces. See this post from the m0n0wall mailing list for an example.

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





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:



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.

Tip: Blocking SMTP on a Captive Portal has been the subject of discussion on the m0n0wall mailing lists in recent weeks. While some see it as protecting the network they are providing from being used for spamming, others see it as being at odds with providing free, unrestricted access to the Internet.

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.







Copyright © Tom's Guides Publishing LLC 1996 - 2005 and printed from TomsNetworking
http://www.tomsnetworking.com/
All rights reserved.
It is illegal to copy or redistribute this information in any way without the expressed written consent of Tom's Guides Publishing.

Please use the Content Permission Form (http://www.tomshardware.com/site/submission/content.html) for such requests.