> OK, it gets more interesting ;> Indeed! Lots of in-line comments, or just skip to the "executive summary" at the end :-)
<config info snipped> > [3] As it turns out, some name resolution stuff works (e.g., nslookup); > but, other stuff does *NOT* work (e.g., host, dig, ping). tcpdump > output is here: > > <http://www.helices.org/tmP/bluetrout.tcpdump.txt> > > [4] I need help understanding what is going on in lines like this: > > 64.4.197.69 > 64.4.197.65: icmp: 64.4.197.69 udp port 32868 unreachable [tos 0xc0] > > I am confused with both icmp and udp specified on same line ??? > > Clearly, I am very close to accomplishing my task! There is a basic mis-configuation in DNS. We've known this for a while, but this is the first hard evidence provided that can be used to pinpoint the trouble. I'll examine two characteristic exchanges from your link above: WARNING - lines will wrap...my comments indicated by CS> at start of line for clarity. -------------------- Ping by name (DNS resolution fails): -------------------- [ # ping 12-248-253-86.client.attbi.com ping: unknown host: 12-248-253-86.client.attbi.com ] 18:38:16.769454 64.4.197.69.32868 > 192.168.1.254.domain: 28463+ A? 12-248-253-86.client.attbi.com. (48) (DF) CS> The initial DNS query, trying to resolve 12-248-253-86.client.attbi.com. CS> Note destination IP (DNS server) = 192.168.1.254 18:38:16.769454 64.4.197.65.domain > 64.4.197.69.32868: 28463 1/0/0 A 12.248.253.86 (64) CS> The response from your DNS server. CS> Note source IP = 64.4.197.65, which *DOES NOT* match DNS server IP, above 18:38:16.769454 64.4.197.69 > 64.4.197.65: icmp: 64.4.197.69 udp port 32868 unreachable [tos 0xc0] CS> The system initiating the query barfs on the response from the wrong IP, returning a port unreachable error. 18:38:21.779454 64.4.197.69.32868 > 192.168.1.254.domain: 28463+ A? 12-248-253-86.client.attbi.com. (48) (DF) 18:38:21.779454 64.4.197.65.domain > 64.4.197.69.32868: 28463 1/0/0 A 12.248.253.86 (64) 18:38:21.779454 64.4.197.69 > 64.4.197.65: icmp: 64.4.197.69 udp port 32868 unreachable [tos 0xc0] CS> And the whole sequence repeats...then ping's DNS query times out, and ping replies with "unknown host" -------------------- nslookup (works): -------------------- [# nslookup -type=PTR 86.253.248.12.in-addr.arpa Server: bluetrout.private.network Address: 192.168.1.254 Non-authoritative answer: 86.253.248.12.in-addr.arpa name = 12-248-253-86.client.attbi.com ] 16:43:21.649454 64.4.197.69.32868 > 192.168.1.254.domain: 54258+ PTR? 254.1.168.192.in-addr.arpa. (44) (DF) CS> Reverse DNS query for DNS server IP (use to populate "Server:" line of nslookup results) CS> Note DNS server (destination) IP is 192.168.1.254 16:43:21.649454 64.4.197.65.domain > 64.4.197.69.32868: 54258 1/0/0 PTR bluetrout.private.network. (83) CS> Response again comes from 64.4.97.65 instead of 192.168.1.254, but nslookup doesn't seem to care, and happily goes on with it's next request of: 16:43:21.659454 64.4.197.69.32868 > 192.168.1.254.domain: 54259+ PTR? 86.253.248.12.in-addr.arpa. (44) (DF) CS> Actual DNS lookup requested at the command line 16:43:21.659454 64.4.197.65.domain > 64.4.197.69.32868: 54259 1/0/0 PTR 12-248-253-86.client.attbi.com. (88) CS> ...and the response. -------------------- So...it looks like either dnscache is mis-configured (bad send-from IP), or more likely, that your masquerade rule connecting the internal network with the DMZ is mangling (masquerading) the return traffic. I'd suggest configuring dnscache to listen on the 64.4.197.65 IP for your DMZ hosts. You can setup a second dnscache to listen on 192.168.1.254 for your internal network. The two tinydns instances can be run on loopback interfaces (there's more than just 127.0.0.1 available, remember...in fact, there's a whole class A) or additional private IP's from your internal network (ie 192.168.1.253) as desired. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
