From: Peter Volkov Alexandrovich <pvolkov@mics.msu.su>
To: John Lange <john.lange@open-it.ca>
Cc: netfilter <netfilter@lists.netfilter.org>
Subject: Re: Problems with OUTPUT rules ESTABLISHED,RELATED
Date: Wed, 03 Aug 2005 09:08:01 +0400 [thread overview]
Message-ID: <1123045682.26557.47.camel@localhost> (raw)
In-Reply-To: <1123016327.12889.200.camel@ws50.darkcore.net>
Hi, again.
On Втр, 2005-08-02 at 15:58 -0500, John Lange wrote:
> Perhaps you can help clarify this for me?
Perhaps. :) But be aware that I'm not a TCP guru. ;)
May be somebody from netfilter mailing list point us to the right
documentation. The general question is at which points of the packet
traversal diagram the connection tracking code changes its state? Or in
which chain/tables syn,ack packet is the part of ESTABLISHED connection?
> According to http://www.knowplace.org/netfilter/ip_overview.html , the
> handshake procedure is as follows:
>
> 1. (B) --> [SYN] --> (A)
> 2. (B) <-- [SYN/ACK] <--(A)
> 3. (B) --> [ACK] --> (A)
>
> I read it as meaning that up until the end of step 2 the connection
> would be NEW. At the end of Step 2 and beyond the connection would be
> ESTABLISHED.
>
> A packet with just the "ACK" flag set can only be part of an established
> connection. quote "The important thing to note here is that after the
> three-way handshake is completed, and the connection is complete, every
> packet that is part of this TCP connection will always have the ACK bit
> set."
>
> So, my understanding is the only way a packet could be generated with
> the ACK flag set and the SRC as my server's IP is as part of an
> established connection.
>
> If that is the case then it should not be blocked because I have an
> OUTPUT rule which allows it.
TCP connection states are not the same as iptables connection states.
And connection tracking code think that connection is ESTABLISHED only
after step 2. But (I hope :)) packet should pass connection tracking
code BEFORE it get INPUT or OUTPUT chain and thus connection should be
at the ESTABLISHED state in this chains. Thus setting just ESTABLISHED
should be Ok.
> Where am I going wrong here?
>
> If I do:
>
> iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
>
> Then all outbound packets are allowed so I definitely don't want that.
I think your problem is in the following rule:
iptables -A INPUT -p tcp --syn --dport 80 -j ACCEPT
change it on
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
Please tell me if this works for you.
Peter.
next prev parent reply other threads:[~2005-08-03 5:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-02 18:59 Problems with OUTPUT rules ESTABLISHED,RELATED John Lange
2005-08-02 19:47 ` Peter Volkov Alexandrovich
2005-08-02 20:58 ` John Lange
2005-08-03 5:08 ` Peter Volkov Alexandrovich [this message]
2005-08-03 9:15 ` Jörg Harmuth
2005-08-03 16:34 ` John Lange
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=1123045682.26557.47.camel@localhost \
--to=pvolkov@mics.msu.su \
--cc=john.lange@open-it.ca \
--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.