Iptables 'hang'

Iptables 'hang'

[David Fokkema]

Hi there!

I have a problem, and I think it is the same as one posted earlier, but
the solution given is not correct. I run kernel 2.4.20, iptables 1.2.7a. I
have this, as a test:

iptables -P INPUT DROP
iptables -A INPUT -p tcp -j ACCEPT

And this will hang my system for about 1 minute. In that time, I noticed
(with the use of tcpdump) that iptables tries to connect to port 111 on my
box using udp. Why? Anyway, because the policy is DROP, it won't connect,
and an ICMP message is not sent back. If I take a policy of ACCEPT, ICMP
messages will be sent and iptables behaves fine. When I want to list my
rules using iptables -L, it again hangs for some time (trying to connect
to 111) and finally gives the list. The rule mentioned above is added, it
only took some time. If I do iptables -nL (notice the 'n') it all works
fine. Why is this? It is very annoying, particulary since another linux
partition on my box doesn't have this problem. If I chroot to that
partition, so using the same kernel version, iptables does not hang. Same
version of iptables, same version of libc. What is going on here? Am I
missing a configuration file somewhere? What does iptables want with udp
port 111? If someone can clear this up for me, I'd be very happy to hear
about it.

Regards,

David

Accessing machine with public ip address.

[Sundaram Ramasamy]

 hi,



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.



How will I set my firewall rules? Please help me on this.





Thanks

SR

Re: Accessing machine with public ip address.

[hare ram]

Hi

what is your Present Iptable rules

where are you accessing ?
what is your PC address ???

what you want to achive

hare
----- Original Message ----- 
From: "Sundaram Ramasamy" <sun@percipia.com>
To: <netfilter@lists.netfilter.org>
Sent: Monday, December 23, 2002 7:28 PM
Subject: Accessing machine with public ip address.


> hi,
> 
> 
> 
> 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.
> 
> 
> 
> How will I set my firewall rules? Please help me on this.
> 
> 
> 
> 
> 
> Thanks
> 
> SR
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Re: Accessing machine with public ip address.

[Sundaram Ramasamy]

Here is my iptables rules

#!/bin/bash
set -xv

EXT="eth0"
INT="eth1"
INT2="eth2"
LO="lo"

ANY="Any/0"

GW_IP="192.168.1.1"
GW_EXT_IP="64.140.18.38"
SUB_NET="192.168.1.0/24"

PRIVP="0:1023"
UNPRI="1024:65535"

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
        echo 1 > $f
done

echo 1 > /proc/sys/net/ipv4/ip_forward

$IPT -P INPUT DROP
$IPT -P OUTPUT ACCEPT
$IPT -P FORWARD DROP

$IPT -X
$IPT -F
$IPT -t nat -F
$IPT -t nat -X

#Fisrt inside Interface
$IPT -A INPUT   -i $INT -j ACCEPT
$IPT -A INPUT   -i $INT -j ACCEPT
$IPT -A OUTPUT  -o $INT -j ACCEPT
$IPT -A FORWARD -i $INT -j ACCEPT
$IPT -A FORWARD -o $INT -j ACCEPT

#Second inside Interface
$IPT -A INPUT   -i $INT2 -j ACCEPT
$IPT -A OUTPUT  -o $INT2 -j ACCEPT
$IPT -A FORWARD -i $INT2 -j ACCEPT
$IPT -A FORWARD -o $INT2 -j ACCEPT

$IPT -A INPUT  -i $LO -j ACCEPT
$IPT -A OUTPUT -o $LO -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


# Second Server web server ( port :  http )
EXT_IP1=216.205.140.8
INT_IP1=192.168.1.130

#ip addr add $EXT_IP1 dev $EXT
addip $EXT_IP1  $EXT

$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.


Thanks
-SR





----- Original Message -----
From: "hare ram" <hareram@sol.net.in>
To: "Sundaram Ramasamy" <sun@percipia.com>; <netfilter@lists.netfilter.org>
Sent: Monday, December 23, 2002 9:19 AM
Subject: Re: Accessing machine with public ip address.


> Hi
>
> what is your Present Iptable rules
>
> where are you accessing ?
> what is your PC address ???
>
> what you want to achive
>
> hare
> ----- Original Message -----
> From: "Sundaram Ramasamy" <sun@percipia.com>
> To: <netfilter@lists.netfilter.org>
> Sent: Monday, December 23, 2002 7:28 PM
> Subject: Accessing machine with public ip address.
>
>
> > hi,
> >
> >
> >
> > 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.
> >
> >
> >
> > How will I set my firewall rules? Please help me on this.
> >
> >
> >
> >
> >
> > Thanks
> >
> > SR
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>

Re: Accessing machine with public ip address.

[Joel Newkirk]

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