Mailinglist Archive: opensuse-security (465 mails)

< Previous Next >
RE: [suse-security] DNAT / routing problem ...
  • From: "Reckhard, Tobias" <tobias.reckhard@xxxxxxxxxxx>
  • Date: Tue, 11 Dec 2001 08:33:56 +0100
  • Message-id: <96C102324EF9D411A49500306E06C8D1A56C9D@xxxxxxxxxxxxxxxxx>
> > 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?

HTH
Tobias

< Previous Next >
Follow Ups