Re: Accessing machine with public ip address.

[Joel Newkirk <netfilter@newkirk.us>]

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