Whoops, my apologies, I should have caught up on reading the other posts
before replying so I knew what functionality was slated for the project.
We have already accomplished some of what is being discussed, however, it
requires us to have a server on each site, doing this at the first hop (i.e.
the m0n0wall) would be more preferred. To prevent having a server on each
site we're forced to use a vendor product right now. The vendor product
does this on the first hop and accomplishes the tasks listed here:
1. When it receives client traffic it determines if the session (based on
the MAC address) has authenticated or not.
2. If the MAC is unknown or has not been moved to the allowed ACL then it
drops all traffic on all ports except for 80 which it redirects to an SSL
web page with a login screen. The client either logs in or creates an
account, then logs in.
3. Once the client's MAC has been identified as being OK it's moved from the
drop list / rule to the allowed list / rule. The session times out after a
specified time so as not to leave open slots for people to jump on.
4. Lastly, which I thought was interesting, the client continues to use SSL
for the entire session. Unbeknownst to the average end-user their entire
session is encrypted. When the device proxies their request it goes back to
regular port 80, 25, 110 traffic on the wired network and out to the
Internet, but anything between the client and the first hop, e.g. the
wireless network is encrypted. The browser (tested IE, netscape, opera,
mozilla, and konquerer) doesn't seem to care if it's sending SSL traffic
over port 80 and somehow the device is able to force mail clients to use SSL
I've used SSH, PPTP, L2TP, IPSec, etc. all over the connection described
above without any special configuration. I've sniffed this configuration
extensively. All the ARP, RARP, DHCP, etc. are all obviously sent in the
clear, but everything else is encrypted. Even if a MAC is spoofed the
would-be war driver would still have to have an account to gain access and
all account information is wrapped in SSL like the rest of the 'real data'
traffic. This configuration has worked suprisingly well and we have it in
production a several sites.
I don't mention all of this functionality to boast a vendor product, but
rather give some insight to what some of the off-the-shelf products are
doing in hopes that it may aid in the design or deliverable requirements of
this project. (I won't mention the vendor name, don't want to give free
advertising, I will tell you who we're using however if you email me
As our workaround stands right now we can't put it in production. As I
said, it requires a server at each site and this is what is stopping us from
deploying it already. Our tech officer has been very successful in getting
all of the following to work however, in a dev environment.
1. Doleing out 2 IPs as someone already mentioned, we call this 'live net'
and 'dead net'. The first one is only used to establish a tunnelled
connection which then the second, routeable, IP is passed through once
authentication is confirmed.
2. We've been able to use L2TP, PPTP, and PPPoE as the tunneling protocol
for this connection.
We haven't been focused on the 'captive portal' aspect of our own
configuration, concentrating first on security instead. Once the session is
established I suppose it wouldn't be too much work to redirect the first
port 80 request. We also wouldn't have to tie radius authentication into
the redirected page since authentication had already been taken care of with
the tunnel. The two main drawbacks to this approach is that it requires the
client to have installed and configured a tunneling client. The second is
that we have to have a server on each site. There was a question of someone
statcing an address out of the routeable pool if they new the address, but
this is handled by the tunnel. That subnet is dropped, except when it comes
through the tunnel, and it obviously can't come through the tunnel unless
they've connected and authenticated via the tunnel.
I looked at the requirements on the project page and noted that
authentication is out of scope, but in my humble opinion the redirect is of
limited importance and use without authentication built in.
Just my .02,
> I'm interested in this as well, and would be willing to contribute a few
> hundred dollars. Can you give more details please? We currently use
> (http://www.xoops.org) and E-XOOPS (http://www.e-xoops.com) for our portal
> needs now. The idea of doing a scaled down version on or through an
> appliance sounds interesting. What are your thoughts on the
> Webmail, radius authentication to wireless access or email through an html
> or PHP front-end, a simple community page with a calender?
> ~Jason Grimm
> Co-Founder, CEO, & Chairman
> FreedomLink, Inc.
> 1.866.221.9920 x709
> jason dot grimm at freedomlink dot net
> ----- Original Message -----
> From: "Benjamin H. Henry" <m0n0wall at id3a dot net>
> To: <m0n0wall at lists dot m0n0 dot ch>
> Sent: Friday, April 23, 2004 10:18 PM
> Subject: Re: [m0n0wall] reward for captive portal support
> > I can donate an additional $25.
> > --
> > Benjamin H. Henry
> > Magothy Networking, LLC
> > On Wednesday 21 April 2004 06:48 pm, Michael DeMan wrote:
> > > Add another $100 to the kitty from OpenAccess.
> > >
> > > - mike
> > >
> > > Michael F. DeMan
> > > Director of Technology
> > > OpenAccess Network Services
> > > 360-647-0785 x204
> > > michael at staff dot openaccess dot org
> > >
> > > On 4/21/04 2:09 PM, "Michael Mee" <mm2001 at pobox dot com> wrote:
> > > > I'd really like to use m0n0wall in more community projects, but the
> > > > of captive portal support kills it in most instances (at least here
> > > > litigation crazy USA). As the technical skills of the people
> > > > us are dropping (a good thing - we're reaching a wider audience),
> > > > becoming more noticeable and frustrating. We also love the 'one
> > > > file' that m0n0wall provides vs the multiple files needed to
> > > > say, pebble, and the inability to easily save those changes.
> > > >
> > > > So... I'm offering US$100 to anyone who can build the required
> > > > and work with Manuel to add it into the standard release of
> > > > Included in this offer is *another* $100 to Manuel to reflect both
> > > > work he's done to date and the work doubtless involved with
> > > > even the best made additions. Its not much, but its $200 out of my
> > > > pocket, not some corporation, that I'd like to give directly to the
> > > > individuals involved, and indirectly to the m0n0wall community.
> > > >
> > > > I'm hoping others who also need this functionality will sweeten the
> > > > and match my offer to make this even more worthwhile for someone
> > > > Manuel). Email me if you're interested.
> > > >
> > > > More info about the feature set and Manuel's integration
> > > > here:
> > > > http://socalfreenet.org/captivewall
> > > >
> > > > More info about the reward and latest value is here:
> > > > http://socalfreenet.org/captivewall/reward
> > > >
> > > > I realize this is may be an unorthodox approach to Open Software
> > > > development, but I hope you'll react in the spirit in which it is
> made -
> > > > an honest attempt to spur the addition of a useful feature that many
> > > > use.
> > > >
> > > > cheers, michael
> > > >
> > > >
> > >
> > > > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > > > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch