On Monday 23 December 2002 10:06 am, Sundaram Ramasamy wrote:
{ liberally snipped }
> Here is my iptables rules
> EXT="eth0"
> INT="eth1"
> INT2="eth2"
> $IPT -A FORWARD -i $INT -j ACCEPT
> $IPT -A FORWARD -o $INT -j ACCEPT
> $IPT -A FORWARD -i $INT2 -j ACCEPT
> $IPT -A FORWARD -o $INT2 -j ACCEPT
> $IPT -t nat -A POSTROUTING -o $EXT -j MASQUERADE
>
> $IPT -A FORWARD -i $EXT -m state --state ESTABLISHED,RELATED -j ACCEPT
> $IPT -A FORWARD -i $EXT -m state --state NEW -j ACCEPT
> $IPT -t nat -A PREROUTING -i $EXT -d $EXT_IP1 -p tcp --dport 80 -j
> DNAT --to $INT_IP1
> $IPT -A FORWARD -p tcp --dport 80 -d $INT_IP1 -j ACCEPT
> $IPT -t nat -A POSTROUTING -o $EXT -s $INT_IP1 -j SNAT --to $EXT_IP1
> I have forwarded 216.205.140.8 to 192.168.1.130. I am accessing web
> page from 192.168.1.140 machine.
> > > I have NATed public 216.205.140.8 IP Address into local
> > > 192.168.1.130 Network address, from my LAN I was not able to
> > > access my machine using public IP Address.
Several problems here. The source of your specific stated problem is
that you are not DNATting the packets. You specify "-i $EXT" for your
prerouting DNAT, and requests from the LAN will NOT appear as input from
that interface, but from $INT or $INT2. Remove the "-i $EXT" and it
will DNAT all packets going to $EXT_IP1 port 80, whether from the
internet or from the LAN.
If the clients are on the same subnet as the server at 192.168.1.130 (or
if the server has any valid route back to the LAN clients that does NOT
pass back through the firewall box) then you also need to SNAT packets
from LAN clients in POSTROUTING that go to the server, changing their
source IP to the IP of the interface they go out on to reach the server.
This way the server will always return traffic back through the firewall
to be unDNATted, and the client will recognize the response to its
request. Something like:
$IPT -t nat -A POSTROUTING -d $INT_IP1 -j SNAT --to $192.168.1.x
using the firewall box's IP for the interface that it reaches
192.168.1.130 through. To avoid the extra overhead of SNATting all
traffic from the internet as well, which isn't necessary, you can use
this rule twice, with "-i $INT" and "-i $INT2", or specifying source IPs
as a subnet matching all local client IPs. (like "-s 192.168.1.0/24"
perhaps)
Forwarding needs an overhaul here. First you accept anything coming in
$INT. A little loose perhaps, but ok, as long as the LAN can be
trusted... Then you accept anything directed out $INT. Quite a bit
looser, and could be considered a problem. Then you do the same two
things for $INT2. Together these four rules accept absolutely
everything EXCEPT forwarding packets from $EXT (internet) right back to
$EXT. Then you go on to accept ESTABLISHED & RELATED inbound at $EXT,
which is fine, but follow it up with accepting all NEW packets there as
well. At this point the ONLY packets left that have not already been
accepted would be ones with state INVALID. Your dport 80 ACCEPT rule
further down will never match, unless the packet is INVALID, meaning
either it is unidentifiable, or it's state cannot be determined.
I would NOT recommend using this ruleset in an environment where you want
a secure firewall. Basically all this ruleset does is handle
forwarding. The only thing that saves you from harm is probably the
fact that (at least as shown here) the only services you actually DNAT
are dport 80 requests targeting EXT_IP1. This is essentially the only
filtering actually done, and you aren't doing it in the filter table,
but rather in the nat table's PREROUTING chain. That is the purpose of
the filter table. (INPUT, OUTPUT, and FORWARD chains)
You would probably be much better served if you remove both the -o
forward rules, remove the "-i $EXT" from the EST/REL forward rule, and
replace the -i $EXT state NEW rule with explicit rules for what dports
you wish to allow the unwashed masses on the internet to actually
access. (basically --dport 80 in this case, it seems) To get things a
little tighter, remove the FORWARD rules for input from the two local
interfaces, and replace them with specific destport rules as well.
There's no reason to make things easy for viruses, spyware, phone-homes,
and other usually quite undesirable communications 'clients'.
Finally, it appears that you have a static IP address for $EXT_IP1,
correct? If so, you are incurring quite a bit of overhead by using
MASQUERADE, which won't even work without
echo "1" > /proc/sys/net/ipv4/ip_dynaddr
to enable tracking of the dynamic IP of the interface MASQ is being
applied to. You should probably be using this instead:
$IPT -t nat -A POSTROUTING -o $EXT -j SNAT --to $EXT_IP1
A very useful 'tool' for following this kind of thing is:
"cat /etc/init.d/firewall | grep FORWARD"
or whatever the path and filename are for your firewall script, and check
each chain. Then you can examine the sequence of rules, and determine
what will be accepted at each stage. Organizing the rules in groups the
way you have makes them more readable, perhaps, but can make it harder
(especially if you have 100+ rules, or even more than one screenful) to
really follow the overall effects.
It might be more useful if you define all your substitions at the very
start, then list the rules for each chain start to finish before the
rules for the next chain. The variable names you use will still make it
clear what rules are related to which interface. (I'd suggest INT1
instead of INT, and HTTP_SVR or some such instead of INT1_IP, to make
them more meaningful) The 'tool' suggested above can be invoked with
"grep INT2" for example, for the (probably rare) occasions when you
really need to see everything relating to that interface in an unbroken
group.
j
