Date: Fri, 14 Mar 2003 15:00:13 -0500 (EST) From: "Dan Mahoney, System Admin" <danm@prime.gushi.org> To: Mark Johnston <mjohnston@skyweb.ca> Cc: "'Tracy, John'" <tracy@covenant.edu>, <isp@freebsd.org> Subject: Re: DNS Proxying based on source address Message-ID: <20030314133430.D39684-100000@prime.gushi.org> In-Reply-To: <005001c2ea47$895398d0$be0fa8c0@MJOHNSTON>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Mar 2003, Mark Johnston wrote: Well, okay, you've overlooked the basic issue I'm having with all of this. DNS uses UDP. UDP is connectionless. With ipfw fwd on tcp, the KERNEL is handling the connection, so for smtp, which I do on 2525 via this same mechanism, as far as I understand it it's client-->local machine port 2525-->kernel-->local machine 25 and the responses go: local machine (whatever port it's responding on, not 25)-->kernel-->local machine's initial connection response port-->client The kernel handles both sides of this transparently, again, as I understand it. Because it's on the same machine, and is a persistent connection, the sendmail on port 25 still sees the original source address, and the kernel handles sending it back out on the original response port for the port 2525 connection. Easy enough... Now, with UDP, where there's no connection it's Local host port 53 - - - > some alias ip port 53 - - - > (and again, this machine will see the original ip of the client as the source). reasonable, and what we want. But because there's no in-place connection, I STRONGLY SUSPECT that the responses will go more like alias ip port 53 - - - > client machine. this is the kicker, and the question I was asking about. Won't most clients ignore the udp traffic if it's coming from an ip they didn't make the request of? Remember, these are both reachable ip addresses bound to ed0 or whatnot. Would I need not only an: ipfw add fwd 192.168.1.2,53 from authorizedclientip/32 to mainip:32 but also some means of rewriting the source address of those reply packets? There's a couple ways I can do this: 1) Have NEITHER bind listen on a "real" ip, instead having them both listen on the loopback, on aliases, on port 53. This somehow "feels" like it would work best, since neither dns server is more "real" than the other. 2) Have one dns server (the "dumb" one), listen on the main IP, and the other listen somewhere else. A different port on the main ip feels more feasible than another real ip on the same box. Thing is, I would really LIKE if both ips were world-accessable, transparently. (the real one would be handed off via dhcp afterwards, keeping firewall rules simpler). Hrmmm, I just looked at bind 9's views option (I've been playing with bind 8 previously). Problem is, this would require a named HUP every time this happened if my response were to include ip addresses inside a views statement. Being able to add an ipfw rule and accomplish the same makes it instantanous. Not that I'm horribly concerned that named can't HUP itself in under a second. We're not talking about a large amount of zone files here. Those are my thoughts. Has anyone here successfully proxied DNS using ipfw fwd? -Dan > Tracy, John wrote: > > It would be nice to implement such a system with some sort of > > expiring... such as ten minutes of inactivity or some > > variable like that. Would you use the counters in IPFW > > somehow to count... or something? We're trying to do just the > > same thing with a new wireless LAN we're installing for > > students... IE students boot up, get an IP. No matter what > > URL they try to access, they get a registration page to which > > they must authenticate. Upon authenticating, their > > workstation is allowed access out through the gateway (or > > IPFW box). Then, after some period of inactivity, or a power > > off that registration is automatically killed and to get back > > online, they must reauthenticate. > > Yes, you could easily do exactly that. No need to worry about counters, > though; try ipfw -t show. The dates are the last time the rule was > matched. Just check it from cron with the granularity you want, and > remove the rule if the date's too old. > > > There's a commercial product called BlueSocket which does > > this. It costs $7500 for their basic box... but doesn't offer > > any real benefits over the scenario above--and it's limited > > to 100 active registrations. > > I'm not sure I'd say that it offers no benefits. Bluesocket claims to > implement IPSec and PPTP along with authentication, whereas in the > scheme I described there is essentially no security at all. Of course, > you could implement a secure scheme using encryption and authentication > with a little more effort. Whether that much effort is worthwhile is > up to your particular situation. > > Mark > > > > > -John > > > > > 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. > > > > -- "I wish the Real World would just stop hassling me!" -Matchbox 20, Real World, off the album "Yourself or Someone Like You" --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- 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?20030314133430.D39684-100000>