Incoming packet in wrong chain

Incoming packet in wrong chain

[Tim Ritberg]

Hi!

I got Kernel 2.6.22 und do some Masquerade for my Windows boxes.

My problem get visible in this rule:
Chain INPUT (policy DROP 0 packets, 0 bytes)
113 87963 DROP_LOG 0 --  ppp0 * 0.0.0.0/0 0.0.0.0/0 state NEW

This rule is at bottom of my INPUT-Chain.

Kernel says:
DROP: IN=ppp0 OUT= MAC= SRC=217.13.68.183 DST=91.xx.xx.xx LEN=58 TOS=0x00 PREC=0x00 TTL=59 ID=55058 DF PROTO=TCP SPT=80 DPT=2409 WINDOW=14520 RES=0x00 ACK URGP=0

This ACK packet belongs to surfing WWW and should never get into INPUT-Chain. The problem occurs randomly.
Is this a bug? A why hit a rule for SYN packets at ACK packets?

-- 
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL 
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: Incoming packet in wrong chain

[Eric Leblond]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Tim Ritberg a écrit :
> Hi!
> 
> I got Kernel 2.6.22 und do some Masquerade for my Windows boxes.
> 
> My problem get visible in this rule:
> Chain INPUT (policy DROP 0 packets, 0 bytes)
> 113 87963 DROP_LOG 0 --  ppp0 * 0.0.0.0/0 0.0.0.0/0 state NEW
> 
> This rule is at bottom of my INPUT-Chain.
> 
> Kernel says:
> DROP: IN=ppp0 OUT= MAC= SRC=217.13.68.183 DST=91.xx.xx.xx LEN=58 TOS=0x00 PREC=0x00 TTL=59 ID=55058 DF PROTO=TCP SPT=80 DPT=2409 WINDOW=14520 RES=0x00 ACK URGP=0
> 
> This ACK packet belongs to surfing WWW and should never get into INPUT-Chain. The problem occurs randomly.
> Is this a bug? A why hit a rule for SYN packets at ACK packets?

For Netfilter connection tracking, a NEW TCP connection does not have to
start with a SYN packet. If
/proc/sys/net/netfilter/nf_conntrack_tcp_loose is set to 1 (default),
Netfilter will try to pick up connection. By this mean, it is possible
to recover a connection (in some fail-over case for example), but it
introduces this looking-weird-at-first behaviour.

BR,
- --
Eric Leblond <eleblond@inl.fr>
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/
EdenWall: http://www.edenwall.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJj05dnxA7CdMWjzIRAk2BAJ4p7uOUzgNsTrOrGbg2sVTYEa8bjwCeLowc
tJssXCPP3rJk/isR9cnynvg=
=hb1D
-----END PGP SIGNATURE-----

Re: Incoming packet in wrong chain

[Tim Ritberg]

> For Netfilter connection tracking, a NEW TCP connection does not have to
> start with a SYN packet. If
> /proc/sys/net/netfilter/nf_conntrack_tcp_loose is set to 1 (default),
> Netfilter will try to pick up connection. By this mean, it is possible
> to recover a connection (in some fail-over case for example), but it
> introduces this looking-weird-at-first behaviour.
> 
> BR,
> - --
> Eric Leblond <eleblond@inl.fr>

because of that netfilter put it in INPUT-Chain?
and I wonder why it occurs randomly.
Should I switch  to nf_conntrack_tcp_loose 0?

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

Re: Incoming packet in wrong chain

[Eric Leblond]

Hi,

Tim Ritberg a écrit :
>> For Netfilter connection tracking, a NEW TCP connection does not have to
>> start with a SYN packet. If
>> /proc/sys/net/netfilter/nf_conntrack_tcp_loose is set to 1 (default),
>> Netfilter will try to pick up connection. By this mean, it is possible
>> to recover a connection (in some fail-over case for example), but it
>> introduces this looking-weird-at-first behaviour.
>>
>> BR,
>> - --
>> Eric Leblond <eleblond@inl.fr>
> 
> because of that netfilter put it in INPUT-Chain?
> and I wonder why it occurs randomly.

These packets are often due to ghost connections:
 - packet from a connection "closed" in the middle due to link failure
 - packet from connection open by the people having the IP before you
 - ...

> Should I switch  to nf_conntrack_tcp_loose 0?

You can, there should be no problem with that.

BR,
-- 
Eric Leblond <eric@inl.fr>
INL: http://www.inl.fr/
NuFW: http://www.nufw.org/