Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Mar 2003 09:49:42 -0600
From:      "Mark Johnston" <mjohnston@skyweb.ca>
To:        "'Dan Mahoney, System Admin'" <danm@prime.gushi.org>
Cc:        <questions@freebsd.org>, <isp@freebsd.org>
Subject:   Re: DNS Proxying based on source address
Message-ID:  <002b01c2ea41$5465b280$be0fa8c0@MJOHNSTON>
In-Reply-To: <20030314031614.J60636-100000@prime.gushi.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002b01c2ea41$5465b280$be0fa8c0>