Archived from groups: alt.internet.wireless (
More info?)
On Mon, 8 Nov 2004 00:16:22 +0000 (UTC), Sandy Baby
<bill@microsoft.com> wrote:
>OK.. we are a WISP with a number of installations in the UK (South Wales).
>Currently, we use RADIUS to authenticate the CPE MAC address at the
>customer's premises. This was fine for a single dwellling, but now we
>have the situation where one single bridge (the CPE) is serving 3
>households, all with separate accounts with us.
I'll assume the CPE is a simple wireless bridge that can only bridge
one MAC address and that you're distributing the traffic using a
fairly simple router. How do you keep the 3ea customers from seeing
each other?
>Now, if one of them
>breaches our T&Cs we (at the moment) only have the option of disabling
>the bridge, hence turning off access to the others.
Yeah, that would be nice. If each customer connected through a
different VPN tunnel, or was part of a VLAN, you could seperate the
traffic and control access. The VLAN would work, but traffic
management would be much easier at the IP level with VPN tunnels, than
at the MAC level with a VLAN.
>So, our thoughts of
>overcoming this was to use a captive portal to capture each user (in the
>same way as a hotspot), so each user will be presented with a login
>screen before they get access. The users themselves could be
>authenticated via radius in this way, and so gives us the option to turn
>the bad user off whilst still keeping the good ones on. It also allows
>us to manage bandwidth allocation at a user level rather than at the bridge.
Yeah, that would work, but methinks is a bit messy and limiting.
There would be no easy way to deliver a routeable IP address to any of
the users. The login ordeal is a web page which would need to be
automated. Client side traffic management is a must or you will have
the 3ea customers argueing with each other over who's hogging the
bandwidth. It might actually be easier and cheaper to use 3 wireless
bridges, one per customer, each on the 3ea non-overlapping channels.
Methinks your "captive portal" would work, but I question whether it
is worth the effort for only 3ea users.
>The problem is, we cannot find one for Windows.
For good reason. Windoze is not known for its simplicity, stability,
or low cost. If you were to do this legally, on perhaps a desktop,
you would owe Microsloth for a license. Embedded Windoze systems do
work, but I would hate to be the one doing the testing. Linux, but
contrast, is scaleable down to floppy disk size. There are also
multiple embedded Linux distributions sold with SBC boards designed
for wireless use:
http://www.soekris.com
http://www.pcengines.ch/wrap.htm
List and search for Linux distributions:
http://www.linux.org/dist/
>As I mentioned though,
>we would be willing to go for a Linux version, but only if it was a
>dedicated distro to accomplish this task (we don't want one of the huge,
>general purpose distros - the less there is to go wrong the better!).
Dedicated distributions are usually attached to specific hardware. If
you're willing to change your hardware, I'm sure something can be
found. What you're doing does NOT sound like something that can be
crammed into a WRT54GS or similar small box. Therefore, you would be
looking for either a stand alone PC driving an ethernet connected
wireless bridge radio, or an SBC (single board computah) with PCMCIA
card radios.
>As for 'dynamic firewall', this is just what a captive portal is.
I beg to differ on the terminology, but it's not important.
>1. a http request comes in from a user.
>2. the firewall looks up the MAC address / IP address in it's table of
>allowed users.
>3. if it's not there, show the user a login screen, otherwise let the
>request through.
>4. capture this user login details and send it to our RADIUS server for
>authentication (using a VPN).
Oh. So you're already using a VPN. I don't see the problem. You
have everything you need to manage the bandwidth and deal with the
authentication at the VPN level. If a user becomes infected with a
virus, all you need to do is change the VPN termination configuration
(at the ISP end) for that user, and they're off the air.
>5. on access-accept dynamically modify the firewall rules (i.e. add the
>MAC / IP to the allowed users table) to let the user in.
Oh, so that's where the term "dynamic" comes from. Thanks.
>We already have the RADIUS / billing system running fine, it's just this
> bit that's missing.
Well, RADIUS doesn't necessarily have to be hard wired to authenticate
by MAC address. The client can be setup to pass a digital
certificate, or shared key. If you transfer the authentication
responsibility to the client computah, you can setup 802.1x
authentication and let each computah do its own authentication instead
of just authenticating the CPE. Of course, with multiple VPN tunnels,
that redundant. Just use the VPN to do the login, authenticate, and
bandwidth manage part.
You might get a better answer in the ISP-Wireless mailing list:
http://isp-wireless.com
--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D
http://www.LearnByDestroying.com
Santa Cruz CA 95060 AE6KS 831-336-2558
Facebook
Twitter
Instagram