Unexplained route between eth0 and eth2

I'm sorry, but you don't explicitly say; what is the problem?
That the Internet can't get to your webserver?

The problem is that I can see the DMZ from my internal network and visa versa. There are no routes that I can find that should allow my 10. network to see my 172. network.
I haven't tried to scare myself by seeing what is visable from the outside but it should only be HTTP and SMTP traffic.

Go to console and do:

route -n >/usr/local/httpd/htdocs/routes.htm

then retreive routes.htm in the browser:

admin_url">https://admin_url/routes.htm[/b]

Sanitize your public IPs (for security reasons), and post your routing info here...

Do you have masquerading NAT rules in place to masquerade both your DMZ network and your Internal network independently of each other off of your External interface?  Two NATs butting heads against each other won't carry any traffic across it between the two inside LANs (DMZ and Internal). Use two masquerading rules such as these:

DMZ_NAT  DMZ_Network__ -> All / All  MASQ__External None
Local_NAT Internal_Network__ -> All / All  MASQ__External None

I have exactly the same MASQ rules set and I still have full access from my Internal network to my DMZ network. Only packet filter rules work to limit access. At least that is what I have found.

Dan

SecApp, the output of routes.htm is:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.0.10 0.0.0.0 UG 0 0 0 eth1 
The 192.168.0.10 is a Netgear DSL router in front of the ASL box. There is a port forward of all traffic from the Netgear public IP to the ASL box.

As I said previously, I have checked the USR_FORWARD chain and the routes are shown as the same as I have listed above.
This is quite confusing to me as I can not see how a 10. network can see, let alone talk, to a 172. network given this route information.

In regard to your advice VelvetFog, I can se how this would work but I do not see why it should be necessary to NAT the two networks. There are no routes between them. They should not be able to see each other at all. Right?

I thought, correct me if I am wrong here, that this was what a DMZ did. Put those computers somewhere away from the internal network to increase the security of the internal network. Right?

You have both replied to my other post regarding administering the web sever in the DMZ (thanks) but in reality, at the moment I have no issues with doing this as I have FULL access from my internal network to the DMZ and visa versa. This cannot be seen as good, hence my posts.

Ezekiel says to use packet filter rules. Again, I can see how this might work but cannot see why it should be necessary. What part of DMZ am I not getting here?

Can someone explain, in basic terms, how this can happen? It’s got me beat.    [:S]

Okay, I am really confused now.
After endless failures at trying to creating a packet filter rule to stop traffic from eth2 (10.0.0.0) to eth0 (172.16.0.0) I put an ANY ANY ANY DROP as my first rule.
Imagine my surprise when I could still ping the web server in the DMZ from any PC in my internal network after doing this.
The web server is connected directly to eth2 via a crossover cable and is, naturally, the only device on eth2.
Maybe the pings are going through my BlackBox KVM PS2 ports (sorry).   

How the hell are pings getting from eth0 to anywhere with an ANY ANY ANY DROP as my first rule?   [:S]

Look in the ICMP settings and turn off ICMP forwarding if you don't want pings going through.

Thanks, yes it does seem that it was only pings getting through.   [:$]
It does pose the question though, what part of drop everything (any any any drop) did the pings not understand?
It would appear that the "ICMP Settings" take precedence over any rules in the packet filter.
Does this seem a little weird to anyone else but me?

Thanks for all the input guys, much appreciated. 
I think I have it all sussed now.   [:)]

( I felt that this avatar of mine was starting to get a bit too close to the bone though . . .    )

Pretty much all the features in astaro (proxies, ssh settings, admin settings, ...) take precedent over the packet filter rules.
Otherwise, it would be pretty confusing, although it might be nice if it listed them on the PF page as static/read-only.