On Tue 11 Dec 01 09:33, Reckhard, Tobias wrote:
Then, I could access the SuSE default web server page on
192.168.10.40 or
rather 192.168.72.4.
Do you think it could be because I have to different class C ip ranges on my interfaces (i.e. 10.0.0.0/24 and 192.168.1.0/24)? From the tcpdump outputs, it seems like a new packet is being generated on the external interface and then not routed to the DMZ interface.
No, I don't think so. I'd modified the IP addresses I actually used, for the sake of keeping the addresses we use internally concealed, for rather weak a reason. Actually and factually, I was redirecting from 10.208.1.40/24 to 192.168.72/24. One difference between my setup and yours is that you've got a 28-bit subnet mask on the outside and a /24 one on the DMZ, while I had /24 on both. But that really shouldn't make a difference.
I suggest you try an 'as clean as possible' approach. Delete all iptables chains, shut down the NICs and delete the routing table. Then set up *only* the DNAT by hand and see if it works. I can imagine that you probably don't want to do for access from the external interface, so I suggest you try it on the inside one instead. Set up DNAT to the web server on an 10.0.0/24 address that's unused, so you can assign it as an alias to the inside Ethernet interface of the firewall. DNAT everything going to port 80 on that address to the web server in the DMZ. See if that works. Remember to *insert* the appropriate rule, so the packets don't get killed by a rule that's already in place.
That gives me an idea. Are you sure the DNAT packets from external to DMZ aren't killed by other rules while making the trip across the Linux box?
No, and from my findings from tcpdump I suspect that is what may be happening. I'll give your suggestion a bash and see what happens.
HTH Tobias