[ previous ] [ next ] [ threads ]
 From:  =?WINDOWS-1252?B?lSCV?= <googl3meister at gmail dot com>
 To:  MAALVAREZ at telefonica dot net
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Reenv: Static IP and Captive Portal
 Date:  Tue, 12 Jul 2005 12:35:03 +1000
On 7/11/05, MAALVAREZ at telefonica dot net <MAALVAREZ at telefonica dot net> wrote:
> Hi,
> and thank you for your quick answer.
> I will explain the case properly because my last message was so brief... sorry.
> In my IT School we have often students from companies and our policiy is
> to filter any attempt to use Internet directly. Therefore we have used succesfully
> m0n0wall and the captive portal option to force this visitors to ask our
> IT staff for a temporary user and password (local users have been a great
> idea in the new beta).
> The problem is that this visitors usually use static IP addresses and their
> own DNS servers (it is their home configuration and they don´t want to change
> that as they are returning to their companies in the same day) so when they
> try to browse the Internet the captive portal page doesn´t show as they
> can´t reach our m0n0wall gateway.
> I would like to know if is it possible to use something like proxy ARP in
> the LAN to fake that m0n0wall is their default gateway and DNS server. Once
> they are authenticated and connected I suppose m0n0wall could stop that
> proxy arp service for that IP addresses. I think this is called zero configuration
> and some commercial captive portals use that option.
> I know this is not implemented and it is difficult but I would like to know
> any clues to try developing this on my own.
> Thank you again,

It sounds as though you want m0n0 to enforce a security policy for you?

M0n0 can help, but you are significantly better off to require:
a) all visitors sign a paper document specifying exactly what is
allowed and what isn't, together with the fines/disciplinary actions
for abusing that policy (such as immediate disconnection from the
network, disciplinary action, remuneration for damages caused, etc),
b) if they are going to connect roaming devices to your network, they
either configure them properly (as per policy outlined in (a) above),
or do not connect to your network/service at all.

Simply requiring them to use DHCP would solve your problem, by the
sounds of it, so I'd simply start the policy off requiring that all
visitors MUST USE DHCP, or do not connect to the network.  Sometimes
it helps if you remind them whose network they are connecting to, who
maintains it, who pays for it...

Also, there are a plethora (lots) of tools out there to allow multiple
network configurations to be saved and restored with a few simple
mouse clicks.  IBM thinkpad laptops have a dedicated app for this
purpose - qctray.exe allows you to store multiple network configs and
just load one up with a mouse click or two.  For a free alternative,
I've used NetSwitcher reliably in the past:

Sure, you can go ahead and develop that functionality (it would still
be useful in many situations), but I believe you will need both it and
the Policy above if you really want it to be effective against people
you've already allowed in...