Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> I think I'd return to this original setup, and configure the Linksys box > to forward the DNS ports to horse-nettle. That way, you get to keep the > firewall capability of the Linksys, and still run a DNS server that is > visible to the outside world. Oh, if only I could. Here's what the situation was when I was trying to make that setup work: * The firewall mapped 216.254.79.186:53 -> 192.168.1.2:53. * The DNS server (tinydns) listened on 192.168.1.2:53. When I tried sending a DNS query from a machine outside the firewall (or from a machine whose route to 216.254.79.186 took it out of the firewall and back), the request timed out. Inspecting packet logs revealed: * The machine sending the query sent UDP packets from w.x.y.z:foo to 216.254.79.186:53, and got nothing back from port 53 of anything. * Horse-nettle got UDP packets from 192.168.1.1:foo to 192.168.1.2:53, and sent packets out from 192.168.1.2:53 to 192.168.1.1:foo. I assume that the Linksys is not bothering to remember where 192.168.1.1:foo was originally mapped from -- a NAT box doesn't *have* to keep track of that for UDP, right? -- and simply drops the packet. (Supporting evidence: Part of the Linksys configuration involves telling it what your nameservers' IP addresses are, but it doesn't serve as a caching proxy server or do DNS itself. I think the Linksys needs this information so that when a machine *inside* the firewall queries a nameserver *outside* it, the return packet will get forwarded appropriately. Unfortunately, listing 216.254.79.186 as one of those nameservers didn't help: apparently, this special-purpose UDP mapping only works in one direction.) I described this situation on a mailing list for tinydns users, and got lots of responses suggesting that I run the server on the firewall machine (it would be nice if I could) or on a machine outside the firewall. ("Doctor, it hurts when I do this." "So don't do that, then!") > Setting things up this way really won't work; horse-nettle will have to > do NAT here, not the Linksys. If you really want to set things up like > this, the Linksys isn't really doing anything for you any more, so you > might as well get rid of it. > > If you can get a second IP address from your ISP, another alternative > would be to have horse-nettle and the Linksys in parallel (not series as > they are drawn above) on the WAN; that is, you would plug a hub into the > DSL router, and connect both to it. My ISP (Speakeasy, which I recommend, by the way) has given me 216.254.79.185-186. My plan is to have horse-nettle handle 216.254.79.186 (for DNS, ssh, email, anonymous FTP, and static Web pages) and pass along 216.254.79.185 traffic to the firewall. (Of course, before the crashes, I hadn't figured out how to do this -- either because my instructions in /etc/ipf.rules weren't doing what I expected them to do, or because the kernel's routing tables, having been built up before I rewired the network, were confused. I had corrected some other configuration files, and rebooted, when horse-nettle crashed for the first time.) -- "The big dig might come in handy ... for a few project managers whom I think would make great landfill." --Elaine Ashton == seth gordon == sgordon at kenan.com == standard disclaimer == == documentation group, kenan systems corp., cambridge, ma == - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |