Boston Linux & Unix (BLU) 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

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

crossover cables / OpenBSD crashes



> 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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org