> root@bluetrout:/root > # ip addr <snip lo, ipsec, & brg>
> 7: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 > link/ether 00:a0:c9:9e:57:70 brd ff:ff:ff:ff:ff:ff > inet 192.168.1.254/24 brd 192.168.1.255 scope global eth0 > 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 > 11: wan1: <POINTOPOINT,NOARP,UP> mtu 1500 qdisc pfifo_fast qlen 100 > link/ppp > inet 64.4.222.157 peer 64.4.222.158/32 scope global wan1 > inet 64.4.197.99/32 scope global wan1 > inet 64.4.197.100/32 scope global wan1 > inet 64.4.197.101/32 scope global wan1 OK, now I'm officially confused. You indicate you're running a proxy-arp DMZ, but your external interface isn't ARP capable. I at least need to see your full routing table, and I'm not sure you can setup your DMZ with proxy-arp or routing and maintain full connectivity to the internet (as things stand now, I think you'll at least be loosing access to the network IP and broadcast IP used on the DMZ network), which look like they could be valid IP's (although neither responded to pings or http reqests). Any details of how your ISP is piping the extra IP's to you would also be helpful. They're obviously not routing a subnet to your external WAN IP, which would be more typical, and I'm not familiar enough with ppp interfaces to know if the kernel will recieve packets sent to alternate IP's if the IP isn't configured on that interface (although I'd think it would). Given the above IP configuation, and the firewall rules you posted, I would think a static-NAT or possibly standard routed DMZ would be more appropriate than Proxy-Arp, but apparently things are working as-is (can you verify current functionality of the DMZ? Does everything but DNS resolution work properly?). > > You should have at least two other IP's assigned on this system...the > > IP's assigned to the internal network NIC and the DMZ nic. You can use > > either one of these (or both) as the DNS server IP for your internal and > > DMZ systems. Note, however, that with both internal and DMZ systems > > pointed to the same dnscache process, you can't split off the internal > > (private.network) name-space. If you really need this feature, I think > > you'll need to run multiple dnscache instances, attached to seperate > > IP's, or take the leap to bind 9.x, which supports multiple views. > > <snip /> > > 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. > > 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 don't know. It could be a variety of reasons, including firewall rules, incorrect routing, incorrect packet manipulation (ie masquerading one direction but not the other), or ???. Please provide details related to the above. You claim the query reaches dnscache...what makes you think so, and do you have a packet dump of the traffic including source & destination IP's and port numbers? You also indicate dnscache responds to the query...again, what makes you think so? Do you have an ipchains log or tcpdump output that would verify this? Again, what are the packet source & destination IP's & ports? 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
