RE: Curious problem with my iptable rules.....detailed postinside,help appreciated.

[Krunk <krunkalot@hotpop.com>]

On Sun, 2004-04-18 at 19:11, Rob Sterenborg wrote:
> -s has no parameter ; it's a typo. It should read 192.168.1.0/24 ?
> 
Sorry, the actual script does have that, error in copying over.

> You have set INPUT policy to ACCEPT, so this rule has nothing to do.
I did this since the second client still couldn't connect...I was making 
"double sure" that http access was ACCEPTED.


> I don't know what is working for you. You're executing 2 scripts, where the
> second is overruling the first in some points, some not.
I know that's exactly what my problem is. I have this little script that I wrote
just get things up and going...sort of a "ok, now everything is working
lets build some rules script". But my real script (the larger one) does
not allow internet access to my second client unless I run this little
script first. The reason I'm confused is that before each script is run
all the rules and chains are deleted.....so they *shouldn't* be
affecting one another. This is covered in the intial post.

> Yes. Setting the policy to DROP means filtering.
Cool, that's what I thought...just making sure.
> 
> > $IPT -t nat -A PREROUTING                        -j ACCEPT
> 
> First, you set policy to DROP, next you allow everything with this rule. Why
> are you doing this ?
I was following the general security guideline of "Deny, than ACCEPT".
Setting Policy to DROP intially, than later on..when more packet
filtering rules are in place, setting to accept.

> 
> - Reboot the PC.
> - Don't execute your firewall scripts.
> - Leave the policies of the nat and mangle table alone. Default is ACCEPT
> and that is correct in most cases. AFAICS in your case too.
> - Use filtering rules in the filter table (you can explicitly use -t filter
> or omit it)
> - Use NAT rules in the nat table (-t nat)
> - Use packet altering rules in the mangle table (-t mangle)
> - Don't mix the three above.
> - Start with a small script (only one) and expand the script when it's
> working. What I understand is that you biggest problem is getting NAT to
> work.
> Start with a small script like this (I forgot the RELATED,ESTABLISHED rules
> before) :
> 
> echo 0 > /proc/sys/net/ipv4/ip_forward
> iptables -P INPUT DROP
> iptables -P FORWARD DROP
> iptables -F FORWARD
> iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
> iptables -A FORWARD -i eth1 -o ppp0 -s 192.168.1.0/24 -j ACCEPT
> iptables -A FORWARD -i eth2 -o ppp0 -s 192.168.2.0/24 -j ACCEPT
> iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.1.0/24 -j MASQUERADE
> iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.2.0/24 -j MASQUERADE
> echo 1 > /proc/sys/net/ipv4/ip_forward

After a fresh reboot, the script above enables access to my first client
on eth1 but NOT my second on eth2. However, I've eliminated the nat DROP
policy and now my main script works at boot up. So I can carry on with
my incremental troubleshooting minus the irritating
reboots........Thanks!

The book I'm reading didn't go into detail on why it set the policy of
the nat chains int particular to DROP but included it in the section
which suggested setting all policies to drop before flushing at the
beginning of a script.
Flushing is done to ensure a clean slate for the rule set (obviously)
and setting to Drop is to ensure no packets are passed while the rules
are flushed. 

I understand this is unnecessary/excessive in a soho set-up, but
wouldn't filtering the nat table be a good thing in large networks where
you would want to prevent unauthorized internal ip's from passing
through the nat chain? 

Thanks for all the help.

James