[CLUE-Tech] iptables NAT question on RedHat 7.1
jason at matchingmoms.com
jason at matchingmoms.com
Sat Oct 20 16:21:28 MDT 2001
Thanks, Dave.
I wanted to follow up on the first part of your comments. My physical setup
is below. Could you explain, in more detail, why it is a problem to use the
same hub to route all of these boxes together? I would think the hub
wouldn't care that all are on the same subnet; it just looks at the packets
and finds some ethernet card which matches the front of the packets?
Here's what I think might be a useful log file. It's generated when I type
192.168.0.4 into my browser from 192.168.0.101.
Oct 20 04:06:46 julia kernel: IP INPUT: 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=61456 DF PROTO=TCP SPT=1092 DPT=80
WINDOW=8192 RES=0x00 SYN URGP=0
Oct 20 04:06:46 julia kernel: IP OUTPUT: IN= OUT=eth0 SRC=192.168.0.4
DST=192.168.0.101 LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PR
OTO=TCP SPT=80 DPT=1092 WINDOW=0 RES=0x00 ACK RST URGP=0
Oct 20 04:06:47 julia kernel: IP FORWARD: IN=eth1 OUT=eth0 SRC=192.168.0.101
DST=192.168.0.200 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=
61712 DF PROTO=TCP SPT=1092 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
Oct 20 04:06:53 julia kernel: IP FORWARD: IN=eth1 OUT=eth0 SRC=192.168.0.101
DST=192.168.0.200 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=
62224 DF PROTO=TCP SPT=1092 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0
------------------
| |
| |
| |
| Win98 client |
| |
------------------
|
eth0 (192.168.0.101)
Internet here |
(eventually) |
| |
| |
| |
| |
eth1 (192.168.0.4)--------| |
| | |
------------------ | ------------------
| | -------| |
| Linux | | |
| | | Hub |
| firewall | | |
| | -------| |
------------------ | ------------------
| | |
eth0 (192.168.0.111)------| |
|
|
|
|
|
eth0 (192.168.0.200)
|
------------------
| |
| Linux |
| http/smtp |
| server |
| |
------------------
Date: Fri, 19 Oct 2001 19:19:15 -0600
From: Dave Anselmi <anselmi at americanisp.net>
To: clue-tech at clue.denver.co.us
Subject: Re: [CLUE-Tech] iptables NAT question on RedHat 7.1
Reply-To: clue-tech at clue.denver.co.us
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
More information about the clue-tech
mailing list