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?
>>
>>I have three nics in Bering rc3
>>
>> ________ eth1 10.10.10.0/24 + tinydns private + dnscache
>> public static eth0 | leaf |
>> (Internet) |________| eth2 10.20.20.0/24 (dmz)
>>
>>and that works great with both subnets talking to dnscache,
>>which only needed an extra line in /etc/dnscache/env/IPQUERY
>>like this
>>
>> /etc/dnscache/env/IPQUERY
>> ====================================
>> |10.10.10
>> |10.20.20
>> |127.0.0.1
>> |
>> |
>> |
>
>
> yes, i do this all the time. we have at least three (3) customers with
> networks with at least two (2) internal networks; and, dnscache/tinydns
> work flawlessly in these environments.
>
> however, this is a proxy-arp dmz -- a totally different animal -- on
> that i do not fathom inside and out . . .
>
>
>
>>and the rule in /etc/shorewall/rules:
>> ==========================================
>> |
>> | ACCEPT dmz fw tcp 53
>> | ACCEPT dmz fw udp 53
>>
>>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
Or at least make up something interesting...
> 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.
Do you forward and masq from the dmz to internal or just forward?
Have you posted all the rules you're using for that?
> 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.
good luck,
matt
> remember:
>
> 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
>
> ideas?
-------------------------------------------------------
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
