On Fri, 11 Oct 2002 09:26:54 EST mds wrote:
> I'm beginning to believe that this maybe the problem. Remember, I
> witness the queries in dnscache and witness the answers sent; but,
> nothing gets back to dmz.
Are you sure? Snippets from the ipchains logs you posted
[c] 59:52 output - eth1 PROTO=17 64.4.197.65:53 64.4.197.69:32780
[d] 59:52 input - eth1 PROTO=1 64.4.197.69:3 64.4.197.65:3
seem to indicate otherwise. It looks like the answer is
received by the dmz host (.197.65) and ignored with an
ICMP port unreachable message back to the firewall. Do
you have the ability to run a packet sniffer on the dmz
host (e.g. tcpdump) to verify?
> This is the real problem. If the query reaches dnscache, it processes
> and answers it, why can't the answer get back to dmz?
I think it does get back to the dmz (unless proxy-arp is causing
me to mis-interpret the log entires above) but is ignored. My
guess at the reason is because of the DCD route to .197.69. From
previous emails:
root@bluetrout:/var/log
# ip route
[..]
64.4.197.64/26 dev eth1 scope link
root@bluetrout:/root
# ip addr
[..]
8: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:a0:c9:9e:64:83 brd ff:ff:ff:ff:ff:ff
inet 64.4.197.65/26 brd 64.4.197.127 scope global eth1
I still think using two instances of dnscache in front of two
instances of tinydns would be a cleaner solution if you need
separate DMZ and LAN namespaces. Otherwise you might end up
in routing kludge hell getting this to work.
At the least, I would suggest taking the ipsec0 interface out
of picture and use an address in 64.4.197.64/26 for dnscache.
E.g.:
64.4.197.65:53 tinydns-public
64.4.197.66:53 dnscache
192.168.1.254:53 tinydns-private
with DMZ host resolv.conf of:
nameserver 64.4.197.65 # tinydns-public
nameserver 64.4.197.66 # dnscache
and LAN host resolv.conf of:
nameserver 192.168.1.254 # tinydns-private
nameserver 64.4.197.66 # dnscache
and make sure dnscache doesn't have entries in root/servers
that would cause it to look to tinydns-private. If it does,
you might get private address bleedthrough into the DMZ if
dnscache is ever asked for LAN host information and then a
DMZ host asked dnscache for the same LAN host information.
I suspect the multiple nameserver entry solution directly
above would be less efficient than the dual dnscache
(or a BIND) setup where the DMZ and LAN hosts always get
answers from the same (dnscache/BIND) name server.
--Brad
-------------------------------------------------------
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
