[CLUE-Tech] iptables NAT question on RedHat 7.1

[Dave Anselmi]

Hi Jason,

I think I understand what you're doing.  Pretty bizarre at first look, but ok.
One thing you might try is to simplify your connections.  That will prevent
ambiguous results that won't appear when you switch your firewall to the
Internet.

Try connecting eth0 of the firewall to eth0 of the web server (using a crossover
cable or another hub).  (This can be done on the other side of the hub too - you
don't want a direct path between the 98 machine and the web server.)

You'll have to make sure your gateways/routing are set up correctly, as well as
NAT and such.  That may require redoing the two sides so they use different
subnets - what you've got now uses one subnet and one lan segment.  By
definition, you won't get any routing and you're trying to use the firewall as a
router.  So you won't see what you want even if things are correct.

If you had the subnetting and routing done correctly, you could use your current
setup and the client and server wouldn't be able to talk directly.  To check
that, you might try taking NAT out and see if the client and server can talk
through the firewall (that is, the firewall is routing correctly).  In your
present arrangement, that won't happen.

Here's a play by play on what you sent, in case it helps you understand more of
what is going on.

jason at matchingmoms.com wrote:

> Am grateful for any help . . .
>
> I am trying to access my Linux web server from my Win98 client by running
> through my Linux firewall (192.168.0.4).  However, when I attempt to do so,
> I get a "There was no response.  The server could be down or not responding"
> from the Win98 client.  When I enter 192.168.0.200 directly I see the web
> page fine.

Previous posts about DNS don't apply, I think, because you're using IP numbers
directly (that's the only way to force traffic through the firewall with your
current subnet).

> Here's my firewall setup:
>
> Flushing existing chains
> /sbin/iptables -F INPUT
> /sbin/iptables -F OUTPUT
> /sbin/iptables -F FORWARD
> /sbin/iptables -t nat -F
>
> Setting default policy ACCEPT
> /sbin/iptables -P INPUT ACCEPT
> /sbin/iptables -P OUTPUT ACCEPT
> /sbin/iptables -P FORWARD ACCEPT
>
> Setting up logging
> /sbin/iptables -A INPUT --source ! 127.0.0.1 --protocol tcp --source-port !
> telnet --destination-port ! telnet --jump LOG --log-prefix net log entry
> /sbin/iptables -A OUTPUT --source ! 127.0.0.1 --protocol tcp --source-port !
> telnet --destination-port ! telnet --jump LOG --log-prefix net log entry
> /sbin/iptables -A FORWARD --source ! 127.0.0.1 --protocol tcp --source-port
> ! telnet --destination-port ! telnet --jump LOG --log-prefix net log entry
>
> Enable outgoing NAT
> /sbin/iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 192.168.0.4
>
> Enable incoming NAT
> /sbin/iptables -t nat -A PREROUTING -p TCP -i eth1 -d 192.168.0.4 --dport
> 25 -j DNAT --to-destination 192.168.0.200:25
> /sbin/iptables -t nat -A PREROUTING -p TCP -i eth1 -d 192.168.0.4 --dport
> 80 -j DNAT --to-destination 192.168.0.200:80
> /sbin/iptables -t nat -A PREROUTING -p TCP -i eth1 -d 192.168.0.4 --dport
> 110 -j DNAT --to-destination 192.168.0.200:110

I hate looking at this stuff because I see so many confusing rules, and I don't
play with it enough to know whether they are necessarily confusing or not.  For
example, this piece:

/sbin/iptables -A FORWARD --source ! 127.0.0.1 ...

How would you ever get a source address of 127.0.0.1 in the forward chain?
Forward gets used by stuff coming in one if and going out another.  As far as I
know, local packets (regardless of address) come in on INPUT and go out on
OUTPUT and never see FORWARD.  Still, shouldn't hurt.

Here's your http DNAT entry rewritten per Rusty's guide:

/sbin/iptables -t nat -A PREROUTING -p TCP -i eth1 --dport 80 -j DNAT --to
192.168.0.200:80

Note no -d option and --to rather than --to-destination.  Don't know if that
matters.

Ok, your counters are zeroed and you try to hit the web server.  Here's what
your logs show, packet by packet.  (By the way, you might want to lable log
entries so you know which chain they are from.  But I think I can guess.)

> ---------------------------------------------------------------------------
> After trying to access web server through firewall:
> ---------------------------------------------------------------------------
>
> root at julia /home/generic $ tail /var/log/messages
> Oct 16 04:29:34 julia kernel: net log entry IN=eth0 OUT=
> MAC=00:04:5a:55:87:e7:00:a0:cc:7c:11:05:08:00 SRC=192.168.0.101
> DST=192.168.0.4 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=32017 DF PROTO=TCP
> SPT=1382 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0

This is the INCOMING chain (has an IN but not an OUT).  It's an http packet
aimed at the firewall.  Why is it in this chain?  It should have been DNATed and
sent through the FORWARD chain (again, perhaps your routing stuff is messed up).

> Oct 16 04:29:34 julia kernel: net log entry IN= OUT=eth0 SRC=192.168.0.4
> DST=192.168.0.101 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=TCP SPT=80
> DPT=1382 WINDOW=0 RES=0x00 ACK RST URGP=0

Here's the reply to the first packet (on the OUTPUT chain).  Note the RST flag -
it's a reset packet telling the client "nobody home on port 80" which is true
for your firewall.

> Oct 16 04:29:35 julia kernel: net log entry IN=eth1 OUT=eth0
> SRC=192.168.0.101 DST=192.168.0.200 LEN=48 TOS=0x00 PREC=0x00 TTL=127
> ID=32273 DF PROTO=TCP SPT=1382 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
> Oct 16 04:29:41 julia kernel: net log entry IN=eth1 OUT=eth0
> SRC=192.168.0.101 DST=192.168.0.200 LEN=48 TOS=0x00 PREC=0x00 TTL=127
> ID=32785 DF PROTO=TCP SPT=1382 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
> Oct 16 04:29:53 julia kernel: net log entry IN=eth1 OUT=eth0
> SRC=192.168.0.101 DST=192.168.0.200 LEN=48 TOS=0x00 PREC=0x00 TTL=127
> ID=43025 DF PROTO=TCP SPT=1382 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0

Ok, now we get 3 packets on the FORWARD chain, from the client to the server,
just what you want.  Notice that they are all SYN packets - the first packet
when trying to open a connection.  They all have different IDs, so they come
from 3 different connections (not retransmissions).  There are no replies to
these because at the server, it's going to answer with a source addr of
192.168.0.200 and a dest of 192.168.0.101 - which will go straight to the
client.  Now, the client isn't expecting an answer from the 200 address, it sent
the packet to the 4 address.

To fix this, your firewall needs to do SNAT both directions (now how wierd are
we getting).  So perhaps adding this (right after the other 'outgoing' NAT rule)
will help:

/sbin/iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 192.168.0.111

But it may not, there may be some odd interactions using SNAT on both sides.
Even if this does work, it isn't what you'll use when you connect to the
Internet, so I still think you should rewire your network.

So there's my thinking.  Take a look at the web server logs and see if they jive
with what you're seeing on the firewall.

Dave