m0n0wall Captive Portal Design

Many thanks to the Personal Telco CaptivePortal page which formed the genesis of this page.

User Usage Flow:

1. a new user gets physical connectivity to the network


2. they issue a DHCP request and are assigned an IP address (all
   un-authenticated IP's are firewalled so they can only talk on the local
   segment)


3. As soon as they open their browser they will be forced a local web page
   (see below)


4. this web page will have a "Continue" button which must be pressed by
   the user to continue


5. after they continue their IP is granted access through the
   firewall

Another approach to this (as done by NoCat?) is to hand out very short leases (15 secs) in another range until the user 'Continue's, and then give them a lease that lets them outside. Maybe this would be easier given the questions that Manuel raises.

Open questions:

1. once the user does 'continue' do they have access until their lease
   expires?  (Or when?)


2. do we need to create a separate tracking mechanism or can we piggyback on
   the IP lease mechanism? (which implies, possibly, that static IPs, or
   preassigned-by-MAC DHCP IPs are exempt?)

Admin Tools

1. per development criteria, the captive portal page will be stored in
   config.xml and edited directly in the GUI. I propose a simple page where
   admins can specify all text on the admin page (to allow for localization).
   Note that there is no provision for a graphic due to the config.xml
   restriction




• page heading


• preface text


• legal wording


• continue button text
  

Another approach would be to allow the user to supply xhtml for the whole page - but that requires them to know what code to use for the button, etc. It seems less error prone to assemble the page from seperate pieces.

2. there should be a way to disconnect a given IP which means that


3. there should be a way to view all IPs in use


4. if we decide on a timeout separate from dhcp lease timeout, then we'll
   need to prompt and gather that info

Future Features

We won't try and do everything in this release. Here are some things we can
do next:

1. automatically add throttle rules for each new IP based on a global
   default

m0n0wall Captive Portal Development Constraints

M0n0wall is succesful in large part due to the vision of its designer. Manuel provided the following guidelines that a captive portal needs to meet for him to consider adding it to the core m0n0wall release (taken from Manuel's email):

• adds < 100 KB to the root filesystem


• copes with low-end embedded platforms (think about a 32 MB/100 MHz
  net4511),


• have to be put under the BSD license like the rest of m0n0wall


• will be subject to whatever changes Manuel finds appropriate


• all the config in one single place (config.xml)


• all admin via the http interface (no ftp of files)

Manual also asks:

Did you check that it fits in with the rest of m0n0wall
without requiring a complete overhaul thereof? I mean - you know that
ipfilter doesn't do layer 2 filtering, and that ipfw has got a kinda
"reserved" function for the traffic shaper, which must work no matter if the
captive portal is on or off. Same goes for other functions like VPN etc. of
course.

m0n0wall Captive Portal - Links to Existing Implementations & Thoughts

A little googling reveals a few FreeBSD captive portals:

http://www.cc.saga-u.ac.jp/opengate/index-e.html
http://opensplash.qalab.com/
http://software.stockholmopen.net/index.shtml

and a bunch of others (not necessarily FreeBSD based) at:

http://www.personaltelco.net/index.cgi/PortalSoftware

I admit I'm out of my depth here when it comes to the level of hacking required for this, but I figure I know enough to be dangerous and can kick start this conversation, so here goes...

Manuel asked here:

Did you check that it fits in with the rest of m0n0wall without requiring a complete overhaul thereof? I mean - you know that ipfilter doesn't do layer 2 filtering, and that ipfw has got a kinda "reserved" function for the traffic shaper, which must work no matter if the captive portal is on or off. Same goes for other functions like VPN etc. of course.

Two different ways I've heard of implementing captive portals are:
1) change the filtering rules to re-direct newly leased IPs to a specific page, then reset the rules when they're approved
2) change the DHCP server to initially supply very short leases in a different, walled-off, subnet and then provide a new IP when they're approved.

One problem with (2) is that someone might simply create their own static IP in the right (2nd) range, but if (1) proves hard, maybe its a good 80% solution?

I think NoCatSplash is an example of (1), http://nocat.net/download/NoCatSplash/.

Perhaps a better starting point is http://www.geekspeed.net/wicap/, which is a captive portal that runs on OpenBSD (presumably closer to FreeBSD than Linux?).

Btw, for those new to m0n0wall, read the full description of its FreeBSD based underlying software and configuration.

m0n0wall Captive Portal - US$222.50 Reward for Development

There is a $222.50 reward(*), plus 1 yr NYCWireless membership and T-Shirt, to anyone who can add captive portal support and an additional $222.50 to Manuel (m0n0wall's developer) to reflect the work he's done to date and the work doubtless involved with integrating even the best made additions. I'm doing this to try and speed up the appearance of captive portal support which is vital for using m0n0wall in more community projects.

Please email me if you'd like to add to this amount.

The rules are (hopefully) simple:

• The resulting code has to be integrated into the mainstream m0n0wall release. Hence it has to meet the criteria Manuel specifies (which is subject to change as needed).
• The reward is paid in US dollars by whatever legal mechanism is mutually agreed upon and convenient (e.g. either directly or as equivalent goods, or whatever).
• In the event of some confusion about who did what work, the final decision about who gets what money is mine alone. I'll do my best to be fair to all concerned. Its possible that the reward will be split amongst multiple people at my sole discretion.

Feel free to post comments directly to this page or on the m0n0wall mailing list. Thanks! Michael Mee.

---

(*) This total reflects $200 of my own money and, so far, $100 of an anonymous contributor, another $100 from www.openacces.org, $20 from Barry Murhpy and $25 from Benjamin Henry, as well as a contribution from NYCWireless. I'll continue to split contributions 50-50 with the contributor and Manuel.