From: Zheng Da <zhengda1936@gmail.com>
To: Jan Engelhardt <jengelh@computergmbh.de>,
netfilter-devel@lists.netfilter.org
Subject: Re: The module I write seems to have conflict with iptables
Date: Mon, 30 Jul 2007 21:49:06 +0200 [thread overview]
Message-ID: <46AE40B2.4@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0707291508260.9488@fbirervta.pbzchgretzou.qr>
Jan Engelhardt wrote:
> On Jul 30 2007 14:32, Zheng Da wrote:
>
>> I finally find the problem. The problem is not caused by my module, but
>> my configuration of iptables.
>> The original configuration is:
>> iptables -F
>> iptables -X
>> iptables -P FORWARD DROP
>> iptables -A FORWARD -i eth1 -j ACCEPT
>> <------------------change this line
>> iptables -A FORWARD -i eth0 -m state --state ESTABLISHED -j ACCEPT
>> iptables -A FORWARD -i eth0 -p tcp --dport 22 -m state --state
>> ESTABLISHED,NEW -j ACCEPT
>>
>
>
>> If I change the line for the device of eth1 to
>>
>> iptables -A FORWARD -i eth1 -j ACCEPT -m state --state
>> ESTABLISHED,RELATED,NEW
>>
>> It works.
>> The problem is what is the difference between
>> iptables -A FORWARD -i eth1 -j ACCEPT
>> and
>> iptables -A FORWARD -i eth1 -j ACCEPT -m state --state
>> ESTABLISHED,RELATED,NEW.
>>
>
> The first one accepts all packets from eth1, the second only
> EST,REL,NEW -- which excludes INVALID.
>
> INVALID connections do not show up in ip_conntrack I believe, but you can
> make them visible using LOG for example:
>
> -i eth1 -m conntrack --ctstate INVALID -j LOG
>
But it doesn't explain why the change of the configuration can make my
module work correctly.
I think there should be more difference
>
>> I check ip_conntrack in Router, the connections between Client and Server
>> are assured in both configurations.
>> I use Wireshark to capture the packets when in the original
>> configuration. I put the result in the attachment.
>> externel: the packets between Client and Router
>> internal: the packets between Router and Server
>>
>
>
>> Does anyone have any idea?
>>
>
> Post to the mailing list, there are more people to answer.
>
>
>
> Jan
>
prev parent reply other threads:[~2007-07-30 19:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-29 17:06 The module I write seems to have conflict with iptables Zheng Da
2007-07-28 17:35 ` Jan Engelhardt
[not found] ` <46ACEC5A.6040103@gmail.com>
[not found] ` <Pine.LNX.4.64.0707291042080.9488@fbirervta.pbzchgretzou.qr>
2007-07-30 19:25 ` Zheng Da
[not found] ` <46ADDA66.3030207@gmail.com>
[not found] ` <Pine.LNX.4.64.0707291508260.9488@fbirervta.pbzchgretzou.qr>
2007-07-30 19:49 ` Zheng Da [this message]
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=46AE40B2.4@gmail.com \
--to=zhengda1936@gmail.com \
--cc=jengelh@computergmbh.de \
--cc=netfilter-devel@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.