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-questions" 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>