From: Martijn Lievaart <m@rtij.nl>
To: angico <angico@yahoo.com>
Cc: netfilter@lists.netfilter.org
Subject: Re: strange behaviour
Date: Wed, 28 Feb 2007 18:36:37 +0100 [thread overview]
Message-ID: <45E5BDA5.9050904@rtij.nl> (raw)
In-Reply-To: <768065.25159.qm@web36815.mail.mud.yahoo.com>
angico wrote:
> GREAT, GUYS! IT WORKED!!!!!! I THANK YOU VERY MUCH for the help!
> angico.
>
Well the problem is in your rules in the first place, I cannot beleive
no one caught this.
Let's reiterate your rules:
1 ACCEPT all -- 192.168.0.0/24 boitata.jlm
2 ACCEPT tcp -- anywhere anywhere state RELATED,ESTABLISHED
3 ACCEPT udp -- anywhere anywhere udp spt:domain
4 ACCEPT udp -- anywhere anywhere udp spt:http state NEW,RELATED,ESTABLISHED
5 ACCEPT icmp -- anywhere anywhere icmp echo-reply
6 ACCEPT icmp -- anywhere anywhere icmp echo-request
(by the way, next time post the output of iptables-save, much better readable)
In rule 2, you allow all packets that are tcp and belong to an established session or related session. This means you DON'T allow the ICMP fragmentation needed messages in (dunno if they are deemed related or established, I think the latter). This is where you shoot yourself in the foot. This is why you SEEM to need the clamp-mss option. You don't need that option, your rules are faulty.
Nothing to do with your problem, but let's have a quick look at your other rules:
1) I prefer to match by interface, but YMMV.
3) Only sensible if you run a local nameserver.
4) What does this do?
6) This rule would not be needed had you allowed all RELATED and ESTABLISHED packets in.
I won't go into your OUTPUT rules, they should work together with your input rules.
What you probably want is something like this:
# Default is to drop
-P INPUT DROP
# Let in anything established or related
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# anything not new is dropped right away
-A INPUT -m state ! --state NEW -j DROP
# pings are allowed
-A INPUT -p icmp --type echo -j ACCEPT
# Input from the local network is allowed
-A INPUT -i $LOCALIF -j ACCEPT
# anything else is logged and dropped by the policy
-A INPUT -j LOG
# We allow anything from the box itseld to the outside
-P OUTPUT ACCEPT
(Add approptiate logging rules for safety and debugging)
I think you would do well to read some tutorials on writing IP tables rules.
HTH,
M4
next prev parent reply other threads:[~2007-02-28 17:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-26 16:21 strange behaviour angico
2007-02-28 17:36 ` Martijn Lievaart [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-02-26 15:35 angico
2007-02-26 16:07 ` Cedric Blancher
2007-02-26 12:45 angico
2007-02-26 13:03 ` Askar Ali
2007-02-26 13:23 ` Silvio Fonseca
2007-02-26 14:53 ` Pascal Hambourg
2007-02-26 15:09 ` Cedric Blancher
2007-02-26 15:34 ` Pascal Hambourg
2007-02-26 16:18 ` Cedric Blancher
2007-02-26 17:43 ` Pascal Hambourg
2007-02-27 8:55 ` Cedric Blancher
2002-12-10 4:48 Strange behaviour Arindam Haldar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45E5BDA5.9050904@rtij.nl \
--to=m@rtij.nl \
--cc=angico@yahoo.com \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.