Matthew Schalit wrote: > > Michael D. Schleif wrote: > > thank you, for your continued interest . . . > > > > Matthew Schalit wrote: > > > >>Michael D. Schleif wrote: > >> > >>>"Michael D. Schleif" wrote: > >>> > >>> > >>>>does anybody have a proxy-arp dmz and also running tinydns & dnscache? > >>> > >>>Anybody have such setup that works?
<snip /> > >>But what's not working, because I guess you tried this? > >>Is it routing or dnscache or fw rules? > > > > > > ok, with the default setup, according to: > > > > <http://leaf.sourceforge.net/devel/jnilo/dnscache3.html> > > > > if a dmz name query cannot be answered by tinydns-public, then it just > > times out -- *never* getting to dnscache. > > Let's not get me to that point just yet. How about you tell > me what ip tinydns-public is bound to? > ==> cat /etc/tinydns-public/env/IP > > How about what ip is dnscache bound to? > ==> cat /etc/dnscache/env/IP # cat /etc/tinydns-public/env/IP 64.4.197.65 # cat /etc/dnscache/env/IP 0.0.0.0 what, pray tell, is wrong with the nestat proof, published twice (2x) and ignored twice? root@bluetrout:/root # netstat -anp | grep dns (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 28373/dnscache udp 0 0 0.0.0.0:53 0.0.0.0:* 28373/dnscache udp 0 0 64.4.197.65:53 0.0.0.0:* 28326/tinydns udp 0 0 127.0.0.1:53 0.0.0.0:* 28324/tinydns > Or at least make up something interesting... are you being cute? did i miss the joke? > > with some sleight-of-hand, adding the real external_ip (wan1, _not_ > > tinydns-public ip) and add an ipchains forward rule from dmz to masq'ed > > internal dcd interface, then I see the request _get_to_ dnscache and I > > see dnscache resolve the name and _send_the_answer_ -- however, nothing > > makes it back to the dmz. > > You're missing a route. which one? root@czar:~ # ip route 64.4.197.64/26 dev eth0 proto kernel scope link src 64.4.197.69 default via 64.4.197.65 dev eth0 root@bluetrout:/var/log # ip route 64.4.222.158 dev ipsec0 proto kernel scope link src 64.4.222.157 64.4.222.158 dev wan1 proto kernel scope link src 64.4.222.157 64.4.197.64/26 dev eth1 scope link 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254 192.168.123.0/24 via 64.4.222.158 dev ipsec0 default via 64.4.222.158 dev wan1 > Do you forward and masq from the dmz to internal or just forward? > Have you posted all the rules you're using for that? this could be it: <http://www.helices.org/tmP/ipchains.bluetrout.txt> > > imho, we are missing some crucial ipchains link from dcd out eth1 to the > > dmz -- but, what can it be? > > Please tell me you've added ipchains -l logging to every packet > 1) inbound on dmz nic > 2) outbound from dmz nic > 3) inbound on internal nic > 4) outbound on internal nic > 5) forwarded by any forward rule > > and repost the trail of a dns request from the dmz, judiciously snipping > and trimming if you please. quite honestly, this is a very busy network and to log each and every packet through this router is not a good idea ;< i've avoided going there, unless there is no other way -- which is why i hoped that somebody had already worked the magic. perhaps it is a missing masq chain? until i publish more details, what do you think about what is already published? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ------------------------------------------------------- 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
