Dan Mahoney, System Admin wrote:
I'm doing a project where I want users on a wireless lan to be routed
to a single, wildcard A record, where they will be forced to input
some registration information, and then allowed out into the real
world. Some nice folks at southwestern university have already
written a project that does this called NetReg but they are
requiring a reboot of the client machine and changes to the DHCP lease
file. (which will be stopped and started while the client reboots)
[much snipped]
I'm assuming here that what you want is a system allowing people to
register and get access, but you don't want to have them change their IP
address between when they first boot and when they go live. That
introduces a bit of complication to the matter - read on.
**big question**
Would adding a second address to the loopback device to the system
(and only having the rules fwd to those addresses) solve the source-ip
dilemma? (at least for the DNS, for the http the machine is still
expecting a reply from some ip that is blocked). Is there any way you
all can think of to have the server return a page when the user tries
to access a site via IP (ala a transparent proxy).
It sounds like transparent proxying is exactly what you want. Here's
my take on a solution for you - some parts of it I've tested for a
similar scheme, some parts are speculation.
First off, please reread the paragraph of ipfw(8) starting with fwd
ipaddr[,port], just for reference.
I'd start with an ipfw rule like the following, on the gateway:
ipfw add 65000 fwd $GATEWAY tcp from $INTERNAL to any
That grabs all incoming TCP traffic and redirects it to your own box.
This part I've tested before, in conjunction with Apache - any web
request, no matter the destination IP, will get a response from your
httpd. Other TCP traffic will hit your box and receive a RST or no
response, depending on your firewall rules. If you want to get fancy,
you can listen for other protocols and send custom messages.
Once you've got that rule into place, it's pretty straightforward to add
rules to allow/NAT/whatever traffic on an IP-by-IP basis for hosts that
you want to let out:
ipfw add 64900 allow tcp from $REGISTERED_IP to any
and so on.
You can decide what you want to do for DNS; my testing used BIND 9's
views and ACLs to serve all requests from unregistered IPs with the same
answer for any A query, but just leaving UDP wide open seems all right
to me. Even if people are able to look up names, they can't make any
TCP connections.
Remember here that you haven't got any security; it's trivial to sniff
the network, find someone that has already registered, and take over
their IP. Not much you can do about that except implement a tunnelling
protocol or do some tricks with ipfw2's layer 2 filtering (which still
doesn't help against the dedicated attacker that will change his or her
MAC address.) For a basic registration-required scheme, though, it
seems pretty sound.
Hope this is fairly clear - good luck with your setup.
Mark
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
